[et-mgmt-tools] "Snippet Groups"

[Michael DeHaan]

Aaron Lippold wrote:
> Hello All,
>
> Thanks for the good feedback. It was good to have a new way to think 
> about. So has the group talked about the line between provisioning and 
> CM? I haven't found much online about when the business process moves 
> from the provisioning architecture to the cm architecture. It might be 
> a good thing to throw out to the list.

Generally the idea is once you get to a certain level of complexity you 
will want to use kickstart for setting up your disks, repos, initial 
package lists, and bootstrapping your config management software, so 
that you can stop having to express your entire configuration in 
kickstart scripts or use less maintainable ways of pushing configuration 
files out.   Config management systems tend to describe the way systems 
should "keep being", as opposed to actions that should just happen 
once.   For instance, "this package should be installed at that version 
and this should be running".  

As an example, see 
https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem, 
which uses Cobbler's --ksmeta facility to indicate a mapping between a 
Cobbler profile and Puppet classes.  That probably works similarly in 
other configuration management systems.   Reviews and improvements to 
that doc are welcome as it's been a while since I tried that, and things 
may have changed with Puppet since.   Contributions for how to integrate 
Cobbler with other config management systems are welcome too.    We can 
probably do some work to make that easier in a future release if there 
is a lot of interest in this, though one will never require the other.

In general, we don't want to explicitly link certain config management 
tools with certain provisioning tools and vice versa, as part of the 
power of smaller, lightweight tools is being able to swap things in and 
out, and also being able to use one without the other when you are 
starting out.   Things are more flexible that way.   All it really takes 
to integrate them is a little magic in your kickstart file and a Cobbler 
--ksmeta parameter.

This means that you can assign a webservers profile to a few config 
management classes, and a specific server, if you want, to one more in 
addition to what the profile is assigned to.  (For instance, a server 
could be a "webserver" profile but also be assigned to a class that 
dealt with
something hardware/system specific).

--Michael



>
> This way we can at least have some basic structure so that, like my 
> requests, we can evaluate which bucket they fall into.

There are no buckets, it's more of a large sandbox :)

--Michael


>
> Yours,
>
> Aaron
>
> On Mon, Apr 14, 2008 at 10:52 AM, Michael DeHaan <mdehaan at redhat.com 
> <mailto:mdehaan at redhat.com>> wrote:
>
>     Aaron Lippold wrote:
>
>
>
>         My thinking was to break them up into snippets then for the
>         once I could, define variables to make them more useful.
>
>         What I liked about this was that I could then use the snippets
>         in other places. But perhaps puppet is a good choice or
>         something like it. Although one of the selling points I do
>         want to try to keep is that we are using base technology. I am
>         hoping to keep my provisioning and upkeep system as simple as
>         possible.
>
>
>     Sure.   The above snippet system should work fine for what you
>     want to do.    Essentially the snippet insertion is done /before/
>     running things through Cheetah, so when given to Cheetah the
>     templates look as if they were all part of one big file all along
>     ... so if you do "#set foo = 'bar'" in one snippet (or in the
>     master template), it's valid later on down the line.
>
>     Presently you cannot have one snippet include other snippets
>     through the Cobbler facility, though you can use Cheetah's
>     built-in include if you need that.   Cheetah includes require the
>     usage of "#set global" for passing variables between includes.
>
>     --Michael
>
>
>            --Michael
>
>            _______________________________________________
>            et-mgmt-tools mailing list
>            et-mgmt-tools at redhat.com <mailto:et-mgmt-tools at redhat.com>
>         <mailto:et-mgmt-tools at redhat.com
>         <mailto:et-mgmt-tools at redhat.com>>
>
>            https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>
>
>         ------------------------------------------------------------------------
>
>
>
>         _______________________________________________
>         et-mgmt-tools mailing list
>         et-mgmt-tools at redhat.com <mailto:et-mgmt-tools at redhat.com>
>         https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>
>
>     _______________________________________________
>     et-mgmt-tools mailing list
>     et-mgmt-tools at redhat.com <mailto:et-mgmt-tools at redhat.com>
>     https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools