On Tuesday, January 31, 2012 at 9:39 AM, Nick wrote:
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 aboutthings that already exist -- so it makes sense for Cobbler to lead at first andthen 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 setup, in version control. Puppet seems potentially capable of defining Cobbler'sconfiguration in entirety, but Cobbler's scope is more limited: thedata-structures describing profiles, systems, etc. are inaccessible to Puppet,and Cobbler can only pass a list of class names to Puppet via an external nodeclassifier.
So it seems to make sense to have Puppet configure Cobbler rather than viceversa. Then there is just one point of control: the central Puppet repository ina 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 inone 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 goingto be. You may very well want to say when AA:BB:CC:DD:EE:FF mac address comesup, install base CentOS 6 and give it Puppet classes A and B, and variables x=2 andy=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 thesite-wide configuration is then embedded in Cobbler's internal configs, anddivorced from the rest of it in Puppet.
I know the Cobbler configuration can be snapshotted into git using a hook - I'mcurrently 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 therather meaningless description "API update" whenever I do a "cobbler sync".
I also looked at Cobbler's node classifier, but yet again, to use it assumesCobbler is driving things, and then Cobbler's (perfectly reasonable) limitationsforce a configuration split across Puppet and Cobbler.
Not to mention that as I am using a "masterless" mode, I need more than just amap of node names to classes, I need a way to emulate external resourcedefinitions. (I'm using a variation of that described here [1], which needsexported declarations to go outside the nodes.)
We can also do very clever things about saying that allRHEL distros get additional classes and variables, and different profiles alsoassign certain classes and variables. See the kickstart snippets which we havehere for trivial bootstrapping:Yes, I've seen those. Those snippets assume there's a Puppet master. Butthat'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 themthese Puppet classes":You could also backup your /var/lib/cobbler configuration files in git if you sodesired. There's actually a cobbler trigger for this already that will autocommit changes:Yes, I've also studied those, see above.It's certainly useful and interesting to learn that I seem to be doing somethingdifferent 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 itmeans I can define my systems/profiles in one place, have that informationavailable to Puppet, and configure my provisioning server with Puppet too. Noneed for a hook then, and my changes to Cobbler can be sensibly documented withthe rest of my site-wide changes.
Cheers,N1. Puppet Without Masters:In the section "Backup and Nagios monitoring without storeconfigs"_______________________________________________cobbler mailing list