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.
Autogenerate Examples:
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
modules/users/files/nis-user-list
the init.pp for this modules resolves its user list from this
autogenerated file
modules/users/files/password-list
keeps a list of user password files.
Is anyone doing something similar?
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.
thanks,
Dan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
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 installationUse 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 puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
thanks David, setting custom values in the database and retrieving them seems like a resonable solution for managing values outside of the code repo. I still need to read more about this. Ok, it took me a second to understand how, but this is quite useful and could easily meet my requirements. I need to play with this a little. I can create config files for everything that I care about and have this external script parse those configs, this will surely be more reliable than trying to parse the node definition files. Did you know that we will meet next Monday? regards, Dan Bode --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Le mardi 16 juin 2009 à 11:07 +0200, Dan Bode a écrit :> thanks David, > > setting custom values in the database and retrieving them seems like a > resonable solution for managing values outside of the code repo. I > still need to read more about this. > > Ok, it took me a second to understand how, but this is quite useful > and could easily meet my requirements. I need to play with this a > little. > > I can create config files for everything that I care about and have > this external script parse those configs, this will surely be more > reliable than trying to parse the node definition files.Volcane from #puppet has written a piece of code to get external data : http://nephilim.ml.org/~rip/puppet/extlookup.rb Cheers Nico