Brenton Leanhardt wrote: > +++ Michael DeHaan [05/08/08 08:04 -0400]: > >> Occasionally the question comes up on what puppet/cfengine/other >> integration looks like for Cobbler. So far that answer (for Puppet, >> anyway) has been to use external_nodes, as below, but I think we can do >> better than this. Here's the Wiki page on that: >> >> https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem >> >> How does this idea (to be explained below) sound for those that are >> using Puppet? I think this could be done with a minimum amount of code >> so it wouldn't be too intrusive to non-Puppet users. I don't think >> this was cleanly possible until 1.0, due to the new mod_python services >> infrastructure in Cobbler. >> >> New feature: Cobbler gets a new URL that serves up an external_nodes >> file for a given profile/system name. >> >> http://cobbler.example.org/cblr/svc/op/puppet/system/$name >> OR >> http://cobbler.example.org/cblr/svc/op/puppet/profile/$name >> > > Perhaps, along with these URLs, a few methods to the remote api could > be added for modifying the puppet parameters and classes for a node. > > >> This file returns the YAML file that is required to tell Puppet what >> puppet classes the node gets. >> >> Cobbler also ships a very simple snippet for use in kickstart %post that >> wgets this file when called, saves it, and uses that file to supply the >> answer to "external_nodes". >> > > I'm not sure I understand this part. The external_nodes script is > usually only present on the puppetmaster. I could see having a script > that calls the above URLs to obtain the parameters and classes for a > particular node, but I'm not understanding how kickstart %post could > be used. >
External nodes is usable on each managed guest, the purpose being to make the choice of what classes the /thing/ gets "external" to the puppet master. This way the puppet master can live on a box other than the cobbler server though we can still have a solid mapping between cobbler profiles and puppet classes for those who want that. This is basically how we did things for virt-factory (this is the project that inspired ovirt, which no longer has puppet depencies, but it still has useful ideas in it). You would create the external nodes script in %post and then configure the puppet config file to indicate what external nodes script you were using. > >> We could source the variable assignments out of --ksmeta, so there would >> be no need for additional variables added into Cobbler to support this, >> just some added support code. >> >> For example: >> >> cobbler profile edit --name=webserver --ksmeta="profile=webserver" >> cobbler system edit --name=foo --profile="webserver" >> >> If it makes things easier we could still add a syntax like: >> >> cobbler profile edit --name=webserver --management-classes=webserver >> >> This feature would allow the profiles to be reassigned anytime, as >> needed, as the profile and system level without reinstalling the >> system. You can then manage your IP/MAC/install/config-mgmt >> associations all in one place, without having to hop between 6 or 7 >> different tools. To me, this is exactly what cobbler's goal is --- to >> allow you to do powerful edits in terms of "objects" and /what/ you want >> to get done, not how you want to do it. >> >> Thoughts? >> >> Does cfengine have a similar concept for mapping systems locally to the >> configuration rules they should access? >> >> --Michael >> >> _______________________________________________ >> cobbler mailing list >> [email protected] >> https://fedorahosted.org/mailman/listinfo/cobbler >> > _______________________________________________ > cobbler mailing list > [email protected] > https://fedorahosted.org/mailman/listinfo/cobbler > _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
