Thanks Bas. This is a known issue I'm facing when a variable is defined twice: once under "any" context and once under "LISA_CLUSTER" context, in your case.
In theory redefining a variable should be forbidden, because convergence becomes uncertain. In practice though the variable can get redefined with a new value on each pass. Then which value should you use in the reports (or any other) promise that uses that variable? Should you use both, and report a different message on each pass? I.e. execute the promise twice? Dimitris On Tue, May 24, 2016 at 8:55 AM, Bas van der Vlies < [email protected]> wrote: > I just tested it and my setup to include the proper config files for > different clusters does not work anymore. Here is a reduced examples. The > class LISA_CLUSTER is defined by init_node and now the > cluster_name is unresolved: /var/cfengine/bin/cf-agent -KI -f ./ > test_promise.cf -DRUN > {{{ > error: Unresolved variable '$(cluster_name)/cluster.cf' in input list, > cannot parse > error: Unresolved variable '$(cluster_name)/cluster.cf' in input list, > cannot parse > R: run_test > }}} > > {{{ > body common control > { > version => "$Revision: 4450 $ $Author: bas $"; > ignore_missing_bundles => "true"; > > ## Default handshake protocol to connect to server > protocol_version => "2"; > > > inputs => { > @(g.cluster_inputs), > }; > > bundlesequence => { > @(run.sara_bundles) > }; > # > ## End > } > > bundle common g > { > classes: > > ## do not execute node_init if one of the classes is set via > command line > # > "GOT_INIT" > or => { > "LISA_CLUSTER", > }; > > ## Use realpath instead of variable name else the classes are > activated to late > # > !GOT_INIT:: > "GOT_INIT" expression => > usemodule("init_node","/etc/node_status/cluster"); > > vars: > > UNDEFINED:: > "cluster_name" string => "undefined"; > "cluster_inputs" slist => { > "undefined/dummy.cf", > }; > > LISA_CLUSTER:: > "cluster_name" string => "lisa"; > > any:: > "cluster_inputs" slist => { > "$(cluster_name)/cluster.cf", > }; > } > > bundle agent run > { > vars: > > any:: > "quarterly_bundle" slist => { > "run_test" > }; > > "sara_bundles" slist => { @(quarterly_bundle) }, > policy => "overridable"; > } > > bundle agent run_test > { > reports: > "run_test"; > } > }}} > > > > On 20 mei 2016, at 23:39, Dimitrios Apostolou <[email protected]> > wrote: > > > > Hello list, > > > > As part of fixing CFE-2162 [1] I have rewritten the iteration engine of > > CFEngine, i.e. the backend that makes sure promises are actuated over > each > > element of slists or containers. > > > > [1] https://tracker.mender.io/browse/CFE-2162 > > > > The changes go deep inside the evaluator, and behavioural changes are > > expected, like "cf_null" no longer being treated specially, and other > > more subtle things! So I've prepared an Alpha build of my private branch > > and all testing would be appreciated. You can find the builds at: > > > > > https://cfengine-package-repos.s3.amazonaws.com/experimental/CFE-2162/cfengine-community-3.10.0-0.a1.0.22.i386.rpm > > > https://cfengine-package-repos.s3.amazonaws.com/experimental/CFE-2162/cfengine-community-3.10.0-0.a1.0.22.x86_64.rpm > > > https://cfengine-package-repos.s3.amazonaws.com/experimental/CFE-2162/cfengine-community_3.10.0~a1~22_amd64.deb > > > https://cfengine-package-repos.s3.amazonaws.com/experimental/CFE-2162/cfengine-community_3.10.0~a1~22_i386.deb > > > > Just remember that this is highly experimental code, in preliminary > > stage, so take precautions and run your tests in a VM. And debug output > > (-d) is way too dense at this point, you've been warned. :-) The main > > reason I'm putting this out is to get feedback on compatibility with > > your existing policy. > > > > The big difference of this build should be much better performance in > > policies with nested expansions of slists/containers. > > > > All feedback is appreciated - positive or negative, on all aspects like > > performance, correctness etc. > > > > > > Thanks! > > Dimitris > > > > > > P.S. Sorry for hijacking help-cfengine mailing list, the only purpose is > to catch as much attention as possible; Please respond only on dev-cfengine > which is more relevant to the subject. > > > > -- > > You received this message because you are subscribed to the Google > Groups "help-cfengine" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To post to this group, send email to [email protected]. > > Visit this group at https://groups.google.com/group/help-cfengine. > > For more options, visit https://groups.google.com/d/optout. > > --- > Bas van der Vlies > | Operations, Support & Development | SURFsara | Science Park 140 | 1098 > XG Amsterdam > | T +31 (0) 20 800 1300 | [email protected] | www.surfsara.nl | > > -- You received this message because you are subscribed to the Google Groups "dev-cfengine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dev-cfengine/CALSpUb16Kz_Veaheg7dkP7mgVpTcok%3DY2LTtH8M%2BvES1mc8zCg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
