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
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Reply via email to