The variable is used in the “any” section not defined. If I change it to:
{{{
LISA_CLUSTER::
"cluster_name" string => "lisa";
"cluster_inputs" slist => {
"$(cluster_name)/cluster.cf",
};
}}}
I get the following error message:
12:48 r41n1.lisa.surfsara.nl:/var/cfengine
root# /var/cfengine/bin/cf-agent -KI -f ./test_promises.cf -DRUN
error: Unresolved variable '@(g.cluster_inputs)' in input list, cannot parse
error: Unresolved variable '@(g.cluster_inputs)' in input list, cannot parse
R: run_test lisa
So its looks like the “body common control” can not resolve it.
> On 24 mei 2016, at 12:22, Dimitrios Apostolou <[email protected]> wrote:
>
> 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 |
>
>
---
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/691496D2-FFEB-4C48-8A9E-6127F09273A5%40surfsara.nl.
For more options, visit https://groups.google.com/d/optout.
