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