On 31/01/12 13:06, Michael DeHaan wrote: > This already exists, but you're kinda trying to do it backwards :)
Hm, I'm starting to think I must have contrarian tendancies... > Provisioning happens well before configuration, and Puppet is very much about > things that already exist -- so it makes sense for Cobbler to lead at first > and > then get out of the way. I think I get that, but from my point of view, I don't want have two tools (Cobbler and Puppet) managed independently. Instead, I was hoping to have just *one* definition of how the whole site is set up, in version control. Puppet seems potentially capable of defining Cobbler's configuration in entirety, but Cobbler's scope is more limited: the data-structures describing profiles, systems, etc. are inaccessible to Puppet, and Cobbler can only pass a list of class names to Puppet via an external node classifier. So it seems to make sense to have Puppet configure Cobbler rather than vice versa. Then there is just one point of control: the central Puppet repository in a Git repo. Unified, with no duplication (I hope). This is also the main issue I have with Foreman: I can't put all my config in one version controlled repository. > While, in provisioning, we talk about profiles that haven't been installed > yet, > and we can actually decide what the hostnames for given MAC addresses are > going > to be. You may very well want to say when AA:BB:CC:DD:EE:FF mac address > comes > up, install base CentOS 6 and give it Puppet classes A and B, and variables > x=2 and > y=3. We can do that. Yep, and I think I read enough of the docs to see how to do that. It's neat, yes. As I said, what I don't quite like about it this way is that part of the site-wide configuration is then embedded in Cobbler's internal configs, and divorced from the rest of it in Puppet. I know the Cobbler configuration can be snapshotted into git using a hook - I'm currently doing it - but it does not integrate easily into my Puppet repository. It wants to be in its own branch/own repository, and commit changes using the rather meaningless description "API update" whenever I do a "cobbler sync". I also looked at Cobbler's node classifier, but yet again, to use it assumes Cobbler is driving things, and then Cobbler's (perfectly reasonable) limitations force a configuration split across Puppet and Cobbler. Not to mention that as I am using a "masterless" mode, I need more than just a map of node names to classes, I need a way to emulate external resource definitions. (I'm using a variation of that described here [1], which needs exported declarations to go outside the nodes.) > We can also do very clever things about saying that all > RHEL distros get additional classes and variables, and different profiles also > assign certain classes and variables. See the kickstart snippets which we have > here for trivial bootstrapping: > > https://github.com/cobbler/cobbler/blob/master/snippets/puppet_install_if_enabled > > https://github.com/cobbler/cobbler/blob/master/snippets/puppet_register_if_enabled Yes, I've seen those. Those snippets assume there's a Puppet master. But that's ok, I've adapted them for my own purposes. Well, good enough for now, anyway. > Information about using Cobbler as an external nodes resource is also here, > where you can say, "when this system comes online, give them > these Puppet classes": > > https://github.com/cobbler/cobbler/wiki/Using%20Cobbler%20With%20A%20Configuration%20Management%20System > > You could also backup your /var/lib/cobbler configuration files in git if you > so > desired. There's actually a cobbler trigger for this already that will auto > commit changes: > > https://github.com/cobbler/cobbler/blob/master/cobbler/modules/scm_track.py Yes, I've also studied those, see above. It's certainly useful and interesting to learn that I seem to be doing something different to everyone else. Maybe that's enough to make me reverse direction. However, arguably I could say doing it "backward" is the way forward, if it means I can define my systems/profiles in one place, have that information available to Puppet, and configure my provisioning server with Puppet too. No need for a hook then, and my changes to Cobbler can be sensibly documented with the rest of my site-wide changes. Cheers, N 1. Puppet Without Masters: In the section "Backup and Nagios monitoring without storeconfigs" http://current.workingdirectory.net/posts/2011/puppet-without-masters/ _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
