This already exists, but you're kinda trying to do it backwards :) 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.
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. 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 It probably works best with the config tool in auto sign mode if you want the install to complete in the first pass. 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 This works pretty darn well, and ensures that the two are well connected. I'd say it's pretty widely used among the set of users that use both tools. 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 Hope this helps. --Michael On Tuesday, January 31, 2012 at 6:34 AM, Nick wrote: > Hi, > > Further to a question I asked on the Puppet mailing list, I wonder if anyone > here has had any success managing Cobbler with Puppet which they could share? > > > http://groups.google.com/group/puppet-users/browse_thread/thread/31040119df2158bc/20edbcfeada828bb > > As I said there, what I'd like to do is: > > - write a Puppet node definition manifest for a new machine > - include DHCP, DNS, hostname and network declarations > - commit this to Git > - deploy via Puppet > - have the Cobber server pick the config up and set up PXE, DHCP, and > DNS accordingly (Cobbler being managed via Puppet) > - shortly after, boot a new machine, and during the PXE boot either > - have its MAC address recognised, or > - select the system from a menu > - have it provisioned with the Puppet package and an appropriate hostname > - have Puppet configure it in the pre-assigned role > > Ideally, I'd be able to re-deploy a new Cobbler server in exactly the same way > as another node. > > Puppet modules which allow automating setting up repos, profiles, systems etc. > don't seem to exist on the public internet. > > One way might be to write a Puppet type based on the Ruby library for > controlling Cobbler 2.0 (2.x?) I gather exists here: > > http://www.google.com/url?sa=D&q=https://github.com/duritong/ruby-cobbler&usg=AFQjCNHF8hQJ1ARTe07axqPLRFtlKyeTVA > > However, more recently I've been experimenting with Augeas (from Puppet) to > manage certain config files and I notice there are Augeas lenses (parsers) for > cobbler's settings and modules.conf files. Plus there is a generic JSON lens, > which presumably could handle everything in /var/lib/cobbler/config. > > So another approach might be to use that - although this would would be > bypassing the API, of course, which comes with its own set of problems. > > > > Cheers, > > Nick > _______________________________________________ > 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
