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 “Cobbler” > 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.

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.

On 02/02/2010 12:12 PM, Kelsey Hightower wrote: > On Tue, Feb 2, 2010 at 4:05 AM, Christian Horn <chorn(a)fluxcoil.net&gt; > 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

On 02/03/2010 05:43 PM, Kelsey Hightower wrote: > 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

> OK, well, at least this makes it a little more clear ;-) I don't see why, though, so maybe that's worth another set of paragraphs as well. Currently, as it stands, I just have to strongly disagree with your vision of "replacing Puppet using the Cobbler framework", but that's not actually worth anything without some sort of motivation; In order for Cobbler or Koan to have the same or similar functionality currently implemented through Puppet, along with it's abstraction level, multi-platform capabilities not to even mention the workforce and cloud behind it, is to re-invent the wheel; not a very unhealthy thing to do in certain situations, but very quickly very much pointless if you're not seeking functionality beyond what Puppet will or would do. It might be way more beneficial to work on better integration, and/or to make Puppet meet your expectations. Kind regards, -- Jeroen

I think its a good idea to try and further the configuration management capabilities in cobbler. I don't see doing that as reinventing the wheel. If you can replace the need to set up a separate run time configuration management system, awesome. I would prefer to build fully configured systems as part of the provisioning process over having to setup another system to do runtime configuration management if at all possible. I think a better work flow is to update your provisioning system (cobbler) and rebuild and reboot into a fully configured system. Do you disagree?