On Tue, Nov 9, 2010 at 1:39 AM, Marc Baudoin
<baud...@stg-interactive.com> wrote:
> 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?
>
I have dealt with this topic at length. The main problem with a
solution to this problem is the inability to extend slists, however
there is an alternative, which is to use the ifdefined option to build
a list with undefined elements. My current solution would look
something like this:
bundle common g {
classes:
"web_server" expression => classmatch("ACME_web.*");
"db_server" expression => classmatch("ACME_db.*");
"test_server" expression => classmatch("ACME_.*test.*");
"datacenter_1" expression => classmatch("ACME_.*dc1.*");
"datacenter_2" expression => classmatch("ACME_.*dc2.*");
vars:
any::
"common_seq" slist => {
"bootstrap_checks",
"HelloWorld",
"cleanup"
};
web_server::
"web_seq" slist => {
"apache2"
};
db_server::
"db_seq" slist => {
"mongoDB"
};
test_server::
"test_seq" slist => {
"testbundle"
};
web_server&datacenter_2&Overloaded::
"augment1" slist => {
"migrate_web_workload"
};
any::
"site_seq" slist => {
"@(g.common_seq)",
"@(g.web_seq)",
"@(g.db_seq)",
"@(g.test_seq)",
"@(g.augment1)",
}, policy => "ifdefined";
}
The main challenge is being able to setup the classes at the top
correctly - to ensure each server is associated with the correct
class. Sometime your hostnames are descriptive enough to use regexes
(like in this example), but in other cases you may need to hardcode
hostnames, or use some other identifier to work out what class the
current host is in. Note that a host could be a member of more that
one class, and would get the related bundles included in it's
"site_seq" (which is included in bundlesequence). Once you can do
that, it is easy to create arbitrary class-based exceptions (the
web_server&datacenter_2&Overloaded was an example of that) - where you
add something to the bundlesequence only in very specific conditions.
Having to add these extra lists each time to the site_seq list is
annoying - but in absence of the ability to extend an slist it's the
best we have got.
> 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
>
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
