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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
