gates and classes

[Marty Gehrke]

Does cfengine evaluate classes individually when gated or in a block. I am probably describing that poorly so let me give an example.

 

!class_A_set::

“class_A_set” expression => returnszero(“some command”);

“class_B_set” expression => “class_A_set”;

 

 

When it evaluates this does it check !class_A_set once for both or does it individually. If that case is the former, class_B_set has a chance of being set. If it’s the later than it is my understanding it will never be set. This is because you are basically saying

 

Set class_B_set if class_A_set when class_A_set is not set. A tongue twister for sure.

 

I am thinking it is the later.

 

 

[Aleksey Tsalolikhin]

 !class_A_set::

“class_B_set” expression => “class_A_set”;

The above promise should never happen unless class_A_set changes while the policy is running.

CFEngine does three passes over each bundle so it is possible that class_A_set will flip from OFF to ON.

However I'd encourage you to be straightforward in your policy to aid human comprehension.  (Perhaps use three classes so your infrastructure engineers don't have to model CFEngine executing policy in their heads?)

If you're doing something complicated in your policy where you have to think about CFEngine's order of execution, or try to control the order in which CFEngine evaluates your policy, you are off the CFEngine Way.

Your policy should describe the Desired State, not deal with the details of how to get there.  Try to make your classes explicit and obvious.

Care to share more of the context (the real-world sysadmin problem you are addressing?)

[Ted Zlatanov]

On Mon, 1 Jun 2015 21:13:11 +0000 Marty Gehrke <Martin...@twosigma.com> wrote:

MG> Does cfengine evaluate classes individually when gated or in a block. I am probably describing that poorly so let me give an example.
MG> !class_A_set::
MG> "class_A_set" expression => returnszero("some command");
MG> "class_B_set" expression => "class_A_set";

MG> When it evaluates this does it check !class_A_set once for both or
MG> does it individually. If that case is the former, class_B_set has a
MG> chance of being set. If it's the later than it is my understanding it
MG> will never be set. This is because you are basically saying

The context is stored with each promise independently of the other
promises in a bundle. So the evaluator will check for `class_A_set`
twice.

You may, however, have different results with cf-promises than with
cf-agent, because the former evaluates as much as it can without
affecting the system, while the latter actually will repair promises and
change the system.

Ted