On Mar 24, 2012, at 4:59 AM, Mark Burgess wrote: > Todd, thanks for writing, your ideas are certainly clear, and I will > give them some serious thought.
Hi Mark, thanks for considering them! > The class/variable issue is more complex than it seems, and the ordering > might not always help convergence of classes and variables (something of > a chicken/egg problem). Are you talking about the variable convergence magic that happens after the classes: section is processed? Or…how variables and classes are handled on the second and third passes? Both? Or something else? > I will think about it though to see if there is something that can be made > easier. Thanks! > These changes are not going to make > it into the next release though - they are pretty big issues with the > potential to destabilize and change behaviour. Yes, I totally agree. Any new functions need to be carefully tested, and the execution order idea needs more thought as it could cause unexpected behavior with existing CFEngine policies not written in the internal actionsequence order. -Tod > CTO and Founder > CFEngine > > http://www.cfengine.com > http://www.markburgess.org > Twitter: @markburgess_osl, @CFEngine_news > > > On 03/23/2012 11:39 PM, Oace, Tod R wrote: >> On Mar 16, 2012, at 9:46 AM, Nick Anderson wrote: >> >>> Yep, when I have to do some strict ordering I will also set a negative >>> like "not_has_shortname" right after so that I can tell if something has >>> really not been done yet. Usually I don't need that kind of strict >>> ordering though. >> >> We're doing a bunch of not_has_shortname style classing here. Usually it's >> to use $(other_bundle.variable) if that variable is defined or to use a >> default value if it's not. >> >> >> I have two big wishes to make variable definition (and other things) easier. >> My first wish is for a new function to avoid having to use positive and >> negative classes at all: >> >> vars: >> "my_variable" string => first_defined_value( $(other_bundle.variable), >> "default-value" ); >> >> # or maybe like this: >> >> "my_variable" string => if_else( isvariable("other_bundle.variable"), >> $(other_bundle.variable), "default-value" ); >> >> I think this is both easier to code and simpler to understand than defining >> and using has_shortname and not_has_shortname style classes. And I don't >> think it would be that difficult to code one or both of these extra >> functions. I might even be able to find some time to take a crack at it >> someday. >> >> >> My second big wish is more difficult to implement, but I think it could be >> really good for CFEngine. Basically, I think CFEngine should execute the >> promises within each bundle in the order that they are coded. >> >> Today CFEngine collects a list of files: bundles, and a list of commands: >> bundles, and a list for each other type of bundle. Then it executes all the >> vars promises first, followed by all the classes, followed by each other >> type of promise as defined by the internal actionsequence. So, today it >> executes like this: >> >> vars promise1 >> vars promise2 >> classes promise1 >> classes promise2 >> files promise1 >> commands promise1 >> etc. >> >> Instead, CFEngine could collect a list that contains both the type of >> promise as well as the promise itself. So if a bundle were written in the >> following order, it would also be executed in this order: >> >> classes promise1 >> vars promise1 >> vars promise2 >> classes promise2 >> commands promise1 >> files promise1 >> etc. >> >> It would store the TYPE of promise in the list of promises, and then when it >> is executing the promises it would use that promise TYPE value to call the >> appropriate internal C function for that type of promise. And then there >> would be no needed for the internal actionsequence. >> >> This style of bundle execution could still make up to three passes to ensure >> promises are kept, same as it does today. I think that's still a good idea. >> It would just execute them all in the order written. >> >> This style of execution would solve this classes: v.s. vars: ordering >> difficulty. We wouldn't have to define not_has_shortname classes because we >> would know that the has_shortname promise would be executed first (like it >> was in CFEngine 2). And, this style of execution would also alleviate the >> need to use classing in many situation to chain promises together in the >> desired order of execution. And I wouldn't need my yellow electronic sticky >> note that has the internal actionsequence order anymore. :-) >> >> >> What do you all think? Am I explaining my ideas clearly enough? >> > _______________________________________________ > Help-cfengine mailing list > Help-cfengine@cfengine.org > https://cfengine.org/mailman/listinfo/help-cfengine -- Tod Oace, Intel Corporation <t...@intel.com> _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
