Puppet users - Nov 2012 - Proposed change to the broker RESTful API and CLI to handle parameters needed in additional broker plugins

Hi all;

There has been a separate thread recently in this mailing list around 
adding a Chef broker plugin to Razor.  As this effort has progressed, the 
realization has gradually sunk in that the parameters that are needed for a 
successful a handoff to Puppet might not be the same as the parameters that 
are needed for a successful handoff to Chef.  That has left us with a 
couple of possibilities:

   - Modify the existing broker slice so that it obtains a list of 
   additional parameters from (and callbacks to underlying functions in) the 
   broker plugin codebase itself.  This would have the effect of modifying the 
   CLI and RESTful API for the broker slice on the fly so that it contained 
   just the options that needed for the type of broker plugin that is being 
   built
   - Modify the existing broker slice so that it took the options for a 
   specific type of broker plugin from an external configuration file of some 
   sort.  That configuration file would define the necessary parameters in 
   whatever form the underlying broker wanted to see those parameters defined 
   in (as a manifest for the Puppet broker plugin? as a YAML file or a in Ruby 
   code for the Chef broker plugin?).  Basically, the expected format would be 
   up to the implementers (and supporters) of the each broker plugin.

The concensus amongst the (small) group of developers we''ve discussed
this
with so far seems to be that the second option is more attractive than the 
first.  It would avoid a lot of unnecessary callbacks and a lot of 
(potentially) complicated changes to the broker slice''s interface
(leaving
the CLI and RESTful API consistent for all broker plugin types and moving 
the complexity inherent in supporting multiple Broker plugin types into the 
associated configuration file types).  I would expect that the end result 
would be an API that looked something like the following (for the broker 
slice CLI):

Usage: razor broker add (options...)
    -p, --plugin BROKER_PLUGIN       The broker plugin to use. 
    -n, --name BROKER_NAME           The name for the broker target. 
    -d, --description DESCRIPTION    A description for the broker target. 
    -c, --config-file PLUGIN_CONFIG  A file defining the configuration of 
the broker target 
    -h, --help                       Display this screen.

The additional parameters that were previously included in the API and are 
currently used within the existing Puppet broker plugin (i.e. the 
comma-separated list of servers, which was used to define the master server 
in the existing Puppet broker plugin, as well as the target broker version, 
which was used to define which version of Puppet to install on the node via 
a ''gem install'' command) would now be taken from the
underlying
configuration file (for the Puppet broker plugin and, perhaps, for the Chef 
broker plugin if those parameters are useful in that context).  Any 
additional (implemenation-specific) parameters could also be implemented in 
this fashion without having to worry about the impact of adding those 
parameters to other broker plugin implementations (where they may or may 
not make sense).  It would be up to the implementers and maintainers of the 
specific broker plugin types to define the configuration file format for 
their plugin, the only responsibility that Razor would have would be to 
pass that file off to the associated Razor broker plugin where it would be 
read and used...

That all sounds great on paper, but there are a couple of issues we will 
have to deal with to make this work:

   - The existing Puppet broker plugin is going to have to be changed 
   slightly to pull these two parameters (which previously came in through the 
   CLI and/or RESTful API) from the configuration file
   - We need to sort out how to "upload" this file to the plugin in
the
   case where the RESTful API is being used instead of the CLI.  This would be 
   easier to do if we were passing in a set of name/value pairs (as a hash 
   map), since we''ve already got patterns for doing that in other
slices
   within Razor (the model slice is a good example, where a JSON hash can be 
   used to pass these values via REST).  The issue here is that we''d
like to
   support a more generic "file and/or script" input to the broker
plugin
   (when defining a new broker instance), so this may take a bit of thought 
   (and experimentation) to find something that will work in both the RESTful 
   and CLI APIs...

So, that''s the proposal as it stands today.  We''d welcome
feedback,
comments, ideas, etc. from anyone on this list who is interested, the 
primary discussion for the Chef broker plugin development is going on
here<https://groups.google.com/forum/?fromgroups=#!topic/puppet-razor/dKEz8fj8Cwc>.
Hopefully we can keep this thread focused on the changes that we''re
going
to have to make to the broker slice to support that effort (and the 
development of any other broker plugins that might come our way moving 
forward), along with the impact those changes might have on the existing 
Puppet broker plugin.

Cheers,

Tom

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/oglM2TCqHZEJ.
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.