Hi,
As the number of different types of hosts in my configuration
grows, I wonder what are the strategies for making bundlesequence
and inputs more modular.
I define a class for each type of hosts so, of course, there's
the class approach:
body common control
{
class1::
bundlesequence => { "common" , "specific1"} ;
inputs => { "common.cf" , "specific1.cf" } ;
class2::
bundlesequence => { "common" , "specific2"} ;
inputs => { "common.cf" , "specific2.cf" } ;
}
But what if a client belongs both to class1 and class2?
My main goal is to avoid redundancies. The common parts of
bundlesequence and inputs can go into an slist, that's fine.
I tried to define another slist variable to handle the specific
parts of bundlesequence and inputs. My idea was to begin vith an
empty slist (now that we can use "cf_null") and then add bundles
and inputs for each class the client belongs to. But it's not
possible to use the slist as in:
"specific" slist => { @(specific) , "other_stuff" } ;
and I found no way to add elements to an existing slist.
So I'm stuck here with no elegant solution to my problem.
How do people with a non-trivial configuration deal with this?
--
Marc Baudoin
STG Interactive
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
