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
> cobbler(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/cobbler
>
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler