Dan Bode wrote: > Hi, > > It seems like one of the barriers to the puppet production rollout that > I am working towards will be user adoption. For this purpose, I want to > manage all common tasks with UIs that autogenerate the puppet code, so > that the admins only have to go through the full build process for > custom code changes and not routine processes.
> manifests/managed-server.pp (node group definitions will be an > autogenerated file) > users uses scripts (maybe a GUI later) to add hosts to a group, remove > hosts, move hosts, also used by the kickstart scripts to add hosts after > installation Use http://reductivelabs.com/trac/puppet/wiki/ExternalNodes for that. That way you can add/remove classes and set variables for nodes by letting puppet call out to a script. > To do this correctly, I need to use some of the Puppet core API for > parsing files, maybe a verfiy function or create fucntion. Can someone > point me to a good starting place for these fucntions? Also what is the > expectation for backwards compatibility when using the API internals > (very low, I assume??) Most of the functionality will just be config > files in the files dir for a module that are loaded at run time. While I haven't actually implemented something like this, I've made two designs how I think this could be implemented: 1) storeconfigs based This is pretty straight forward. First you need to define what resource you want to manage externally: | define external::something($param1, $param2) { | # ... | } Then activate storedconfigs and work with the created database: Create a "fake" host, and add the resources to the "resources" table, adding parameters into the "resourcekeep the items with exported='t' and put the params into "param_names"/"param_values". The database schema is quite straight-forward. Finally, you can just collect all the resources from the database where you need them: | External::something <<| |>> See http://reductivelabs.com/trac/puppet/wiki/ExportedResources for more details on the query syntax. 2) function based This way is more involved but would provide you with more flexibility. The point here is to create puppet functions to query your custom database while compiling the configuration for a client: | define external::something::from_db() { | $real_name = name_from_db($name) | $param1 = param1_from_db($name) | $param2 = param2_from_db($name) | external::something { | $real_name: | param1 => $param1, | param2 => $param2; | } | } And use it like that: | external::something::from_db { list_from_db(): } Where list_from_db() returns an array of primary keys, and name_from_db() and param?_from_db() return the name and the values respectivly for a certain primary key. 3) Conclusion Both of the methods avoid touching internal APIs of puppet and thus should be quite stable across releases. Regards, DavidS --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
