On Wed, 14 Dec 2011 10:08:22 +0000 (GMT) Mark Dixon <m.c.di...@leeds.ac.uk>
wrote:
MD> However, it wasn't the "if" bit I was fuzzy about, it was how people use
MD> the language to do the job of an "if..elif..else" construct in the
MD> clearest and least fragile way.
MD> Extending the example on the devops page naively would mean that the
MD> "else" part will quickly become unmanageable.
MD> In my example, I created a third class to play this role and act as a
MD> default:
MD> ...
>>> classes:
>>> location_A expression => classify("$(location_A)");
>>> location_B expression => classify("$(location_B)");
>>> location_unknown not => classmatch("location_.*");
MD> ...
MD> Is this the sort of way people do it in practice?
I try to stay away from inverting classes. Rather, I'll define
something global and then override it for each class that needs it
different. But I've done inversion too, when it's very clear:
bundle common g
{
classes:
"file_exists" expression => fileexists("myfile");
vars:
file_exists::
"root" string => "myroot1", policy => "overridable";
!file_exists::
"root" string => "myroot2", policy => "overridable";
}
In your example, if something defines the "location_unknown" class
previously, suddenly the location_unknown definition will flip. So I
would avoid it for that reason alone--it's not self-convergent.
Ted
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
