Thanks for the feedback, it seems as though I need to add a lot of clarity to the wiki. The goal would remain a runtime tool. Configuration would happen in the same way that Puppet does today.
The goal is to replace puppet using the cobbler framework. I have a prototype that works as you describe. The order of events does not change. One would still provision the machine first, then run Koan or Coan to apply the configuration. This would be very similar to want Cobbler's light weight configuration management does today. I would just like to leverage the cobbler framework to do it. I will add a complete example to the wiki to help clear things up later today. In short, I totally agree with you. On Feb 3, 2010, at 9:48 AM, Jeroen van Meeuwen <[email protected]> wrote: > On 02/02/2010 12:12 PM, Kelsey Hightower wrote: >> On Tue, Feb 2, 2010 at 4:05 AM, Christian Horn <[email protected]> >> wrote: >>> On Mon, Feb 01, 2010 at 08:07:14PM -0500, Kelsey Hightower wrote: >>>> >>>> MadHatter aims to create an advanced configuration management >>>> module >>>> for Cobbler with a feature set similar to Puppet, the open source >>>> CMS >>>> from Reductive Labs. Unlike Puppet, MadHatter will forgo a >>>> configuration language and instead opt for doing things the “C >>>> obbler” >>>> way. >>> >>> Maybe its just me but even i have understandings of cobblers and >>> puppets >>> workings and reading this projectside multiple times i didnt get >>> what >>> you are up to. >> >> Thanks for the feedback, and I agree that this section can use more >> clarification. >> >>> Trying to get puppets functionality without using its language but >>> just with cobbler-tools.. doesnt make sense to me. >>> Besides snippets (which you dont want to use apparently to embed >>> puppet-instructions) there are ksmeta as input-channel, but thats >>> not really a decent interface to somehow get puppets functionality. >> >> Hopefully, I can offer some clarity here. >> > > I'm just hoping I understand you correctly, while I give my $0.02 ;-) > > From where I'm sitting, it pretty much sounds like you want (runtime) > configuration management to get closer onto the provisioning stage. > However, while doing so, you create unnecessary duplicates in that > > 1) The provisioning stage is going to take care of a piece of > configuration, and > > 2) The runtime stage still takes care of that piece of configuration. > > Let me try and emphasize what I mean by this, using two hypothetical, > simple examples: > > == /etc/resolv.conf == > > Suppose that during installation, your /etc/resolv.conf doesn't look > like anything the node requires in order to be able to come back up > after the post-installation reboot. Bootstrapping the installation > procedure makes sense, because this is your one chance to make sure > the > node gets the correct configuration before it even attempts to come > back up. > > Previously (back in the Dark Ages), you would just %post all commands > you needed to change the contents of /etc/resolv.conf to your liking > (a > sed, a awk, you name it), whereas now you can reuse your runtime > configuration management (Puppet with external node support?) and thus > account for /etc/resolv.conf only once, for both purposes > (bootstrapping > the provisioning stage and the runtime stage of a node's life cycle). > > Accounting for /etc/resolv.conf only once makes perfect sense, because > it will need to be changed during the provisioning stage, and possibly > later on during the runtime stage (in a node's life cycle) as well. > You > would want this to need change in one location only (not both Cobbler > and Puppet, sorta speak). > > The goal is to integrate that part of runtime config. mgmt. in a way > that makes a certain sub-set of configuration management available > during the provisioning stage, and whether you bootstrap only the part > of config. mgmt. that makes sure the node comes back up (Life) or > whether you apply Everything and the Universe in the bootstrapping > phase > of the provisioning stage as well, ohw well... who cares? > > == /etc/httpd/conf/httpd.conf == > > I think we all agree this configuration file in no way whatsoever > should > ever be allowed to control whether the node comes back up. > > I think we also agree that this configuration file will eventually > change during the runtime stage of a node's life cycle. > > The point I'm trying to make is that you must account for this file > (and > it's checks and services) in runtime config. mgmt. already. > > It makes no sense to move or copy from a runtime config. mgmt. that is > perfectly integrated with provisioning by means of bootstrapping, to > the > provisioning platform as well. This is duplication that, arguing in > extremes, could defeat the purposes of runtime config. mgmt. (ease of > change, environment staging, consistency, etc). > > I think the very same applies to packages, users, mounts, > repositories, > groups, (config) files, services, dependencies between whatever > combination of this set, and virtually anything else that Puppet has a > type for. > > Kind regards, > > Jeroen van Meeuwen _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
