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@xxxxxxxxxx
<mailto:mdehaan@xxxxxxxxxx>> 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@xxxxxxxxxx <mailto:et-mgmt-tools@xxxxxxxxxx>
<mailto:et-mgmt-tools@xxxxxxxxxx
<mailto:et-mgmt-tools@xxxxxxxxxx>>
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
------------------------------------------------------------------------
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx <mailto:et-mgmt-tools@xxxxxxxxxx>
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx <mailto:et-mgmt-tools@xxxxxxxxxx>
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
------------------------------------------------------------------------
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
