Forum: CFEngine Help
Subject: Re: methods, usebundle and loops
Author: davidlee
Link to topic: https://cfengine.com/forum/read.php?3,24644,24648#msg-24648
Simon,
You say "And I need to check the whole namespace in my production promises for
collisions!"
It's worth adopting for yourself a set of conventions for naming. Alas, the
cfengine documentation doesn't seem to include such a recommendation. And the
standard library sets a very poor example in this respect; its bundle, body and
global-class names are arbitrary when one considers scaling up. But Diego's
example implicitly hints towards such local conventions:
bundle agent echoname(name) {
commands:
"/bin/echo $(name)"
ifvarclass => "!echo_run_$(name)",
classes => if_repaired("echo_run_$(name)");
}
See how his class names "echo..." reflect his bundle name? (Personally, I
would probably use something like "echoname_$(name)" as a naming pattern for
this set of global classes, then there's no risk of clash.)
When I say "no risk of clash", that's a white lie of course. I can immediately
think of two:
(a) You have another bundle of the same name, which would itself be an error.
But that's a different problem, and in solving that (and consistently keeping
with such a convention for your global classes) this particular class-name
clash would go away.
(b) Your name lands up on a name that coincides with one of cfengine's own.
There's no simple solution. But it would be helped if cfengine itself could
suggest a set of naming conventions which kept its own name patterns different
from those of users. (Even if cfengine themselves simply said "all our names
will be "CFE_*"
There are moves afoot to create a framework for users to share bundles. Whilst
this is a potentially good idea, it opens up a worrying nightmare set of
possibilities for name clashes left, right and centre, unless it also has a
clear set of naming conventions, coupled with a set of peer-review gatekeepers
who were alert to detecting and correcting such issues before such bundles went
public.
_______________________________________________
Help-cfengine mailing list
[email protected]
https://cfengine.org/mailman/listinfo/help-cfengine
