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 > > 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. > > Proverbially, I don't think you want to replace all of your tools with a hammer. I'm far beyond the point of caring about which tools people use, it just makes it really *weird* do to so. A Puppet define for each, in particularly, would be horribly slow. JSON files for each ignore cobbler's own validation and side effects, which were put there for a reason. Lots of reasons to use separate tools, you would be shooting yourself in the foot. > > 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. > It's not that simple. There's a reason we didn't implement this when I worked at Puppet Labs :) > > 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. > > The main issue I have with Foreman is the parasitic way users were recruited from this project and the aggressive self promotion :) Would rather not discuss it's name here. > > > 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. > > Using an external-nodes-tool in pretty a much a best practice from the other side of the house. Though I can understand the desire to see the changes in a git RSS feed or something, you would still see that if you used the scm_track module. > > 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". > True, you'd have to look at the diffs to understand what was done. The main point was rollback. > > 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. > > Right, deploy the OS and your configuration separately. > > 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.) > > Point, ext-nodes don't work for you. I wish it did work that way, actually. Ah well. > > > > 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. > > If you did it, you should write set of Ruby types/provider. The provider must speak Cobbler XMLRPC, not JSON. The provider will need to notify a cobbler sync if anything changes. Make sure you don't leak the cobbler username/password to your nodes. Still, I think that's a lot of work and a confusing way to do it. There are basically four pieces to systems management - provisioning - package management / updates - config - monitoring You pick what tools you want for each. I think having config drive provisioning makes about as much sense as having monitoring drive package updates. But that's just me. > > 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] (mailto:[email protected]) > https://fedorahosted.org/mailman/listinfo/cobbler > >
_______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
