Marco,
It appears you are correct. Given this test file:
body common control {
bundlesequence => { "test" };
inputs => { "cfengine_stdlib.cf" };
}
bundle agent test {
vars:
"myfile" string => "/tmp/foo";
classes:
"file_exists" expression => fileexists("$(myfile)");
files:
"$(myfile)"
delete => tidy;
reports:
file_exists::
"$(myfile) exists";
!file_exists::
"$(myfile) does not exist";
}
Here are the relevant lines in the verbose agent output. Note that even
after the file has been deleted, in the 2nd and 3rd iterations the
file_exists class is still defined, which does indeed validate your
belief.
nova> vars in bundle test (1)
nova> classes in bundle test (1)
nova> + Private classes augmented:
nova> + file_exists
nova> files in bundle test (1)
nova> Promise handle: promise_test_cf_16
nova> Promise made by: /tmp/foo
nova> -> Using literal pathtype for /tmp/foo
nova> -> Handling file existence constraints on /tmp/foo
nova> -> Verifying file deletions for /tmp/foo
nova> -> Deleted file /tmp/foo
nova> reports in bundle test (1)
nova> Promise handle: promise_test_cf_20
nova> Promise made by: /tmp/foo exists
nova> R: /tmp/foo exists
nova>
nova> Skipping whole next promise (/tmp/foo does not exist), as context
!file_exists is not relevant
nova> vars in bundle test (2)
nova> classes in bundle test (2)
nova> + Private classes augmented:
nova> + file_exists
nova> files in bundle test (2)
nova> reports in bundle test (2)
nova> Skipping whole next promise (/tmp/foo does not exist), as context
!file_exists is not relevant
nova> vars in bundle test (3)
nova> classes in bundle test (3)
nova> + Private classes augmented:
nova> + file_exists
nova> files in bundle test (3)
nova> reports in bundle test (3)
I interpret this behavior as Cfengine detecting the file existing some
time during this entire run of the agent. I can see how this could
potentially lead to confusing or undesired behavior, but so far it's not
a problem I've run into.
I don't know whether this was Mark's intended behavior for Cfengine, but
either way, as he and many on this list would say, sometimes you need to
step back and reevaluate what you're trying to do and/or why you're
trying to do it. This may be one of those cases.
Can you provide a specific example of how this may be causing a problem
for you? If so, please state your problem as a business requirement
rather than providing example code, which can often confuse matters.
Justin
-----Original Message-----
From: Lebel, Marco [mailto:marco.le...@domtar.com]
Sent: Wednesday, April 21, 2010 3:42 PM
To: Justin Lloyd; fo...@cfengine.com; help-cfengine@cfengine.org
Subject: RE: Cfengine Help: Re: RE: Cfengine Help: cfengine program flow
Justin,
You are bringing an interesting point since I struggle with classes in
this context. But I have not done any structured testing but I am under
the impression that once a class has been set it never gets unset.
Again I want to stress that I never did any exhaustive testing on this
but I believe that classes once set they are set globally (i.e. visible
in all subsequent bundle) and never get unset even if the condition that
initially created it is no longer true... Again the key word is an
impression that needs to be confirmed by someone in the know or has done
the necessary testing.
Marco
-----Original Message-----
From: help-cfengine-boun...@cfengine.org
[mailto:help-cfengine-boun...@cfengine.org] On Behalf Of Justin Lloyd
Sent: Wednesday, April 21, 2010 5:31 PM
To: fo...@cfengine.com; help-cfengine@cfengine.org
Subject: RE: Cfengine Help: Re: RE: Cfengine Help: cfengine program flow
As I understand it, it will reevalute the class promise, and therefore
check for the file's existence, on all three iterations. A good way to
see what is happening is to run cf-agent in verbose mode (cf-agent -vK)
and write its output to a file then read through it. You'll see lines
like this (yours will be prefixed with something other than "nova>"):
[r...@rhn ~]# cf-agent -vK > /tmp/out
[r...@rhn ~]# grep '^nova>.* in bundle .* ([1-3])' /tmp/out
nova> vars in bundle def (1)
nova> classes in bundle def (1)
nova> vars in bundle def (2)
nova> classes in bundle def (2)
nova> vars in bundle def (3)
nova> classes in bundle def (3)
nova> vars in bundle update (1)
nova> classes in bundle update (1)
nova> processes in bundle update (1)
nova> commands in bundle update (1)
nova> files in bundle update (1)
nova> services in bundle update (1)
nova> vars in bundle update (2)
nova> classes in bundle update (2)
nova> processes in bundle update (2)
nova> commands in bundle update (2)
nova> files in bundle update (2)
nova> services in bundle update (2)
nova> vars in bundle update (3)
nova> classes in bundle update (3)
nova> processes in bundle update (3)
nova> commands in bundle update (3)
nova> files in bundle update (3)
nova> services in bundle update (3)
nova> vars in bundle dg (1)
nova> classes in bundle dg (1)
nova> vars in bundle dg (2)
nova> classes in bundle dg (2)
nova> vars in bundle dg (3)
nova> classes in bundle dg (3)
Note how it does 3 iterations of the promise types in bundle "def", then
3 of bundle "update", etc. ("dg" is a custom bundle of mine).
Justin
-----Original Message-----
From: help-cfengine-boun...@cfengine.org
[mailto:help-cfengine-boun...@cfengine.org] On Behalf Of
fo...@cfengine.com
Sent: Wednesday, April 21, 2010 3:22 PM
To: help-cfengine@cfengine.org
Subject: Cfengine Help: Re: RE: Cfengine Help: cfengine program flow
Forum: Cfengine Help
Subject: Re: RE: Cfengine Help: cfengine program flow
Author: nicolas
Link to topic:
https://cfengine.com/forum/read.php?3,16959,16960#msg-16960
thanks for the fast response.
it helps, i thought this is a recommendation :-/ (i should read more
exactly)
but one question i still have:
if i define a class:
classes:
"xy_installed" expression => fileexists("/usr/example");
does it recheck this value each time i use
xy_installed::
or only once at the beginning of each of the 3 times?
regards
nicolas
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
This electronic communication and any attachments may contain
confidential and proprietary
information of DigitalGlobe, Inc. If you are not the intended recipient,
or an agent or employee
responsible for delivering this communication to the intended recipient,
or if you have received
this communication in error, please do not print, copy, retransmit,
disseminate or
otherwise use the information. Please indicate to the sender that you
have received this
communication in error, and delete the copy you received. DigitalGlobe
reserves the
right to monitor any electronic communication sent or received by its
employees, agents
or representatives.
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
