On Mon, Aug 8, 2011 at 5:51 AM, Oliver Hookins <ohook...@gmail.com> wrote:
> Hi all,
>
> Recently I've hit against this problem which is proving to be a
> formidable foe. We have an in-house developed ENC and use
> parameterised classes just about everywhere and as a result enjoy a
> fairly flexible way of handing out configurations and very well-
> defined interfaces between components. We also quite strictly version
> our Puppet code but there isn't a fixed versioning between the ENC
> YAML and the Puppet code that it drives.
>
> Whenever we want to add additional parameters to certain classes,
> unless we update that class and the YAML that drives it atomically
> everywhere, we end up in a situation where the YAML does not match the
> parameterised class and causes errors. Perhaps it is best shown as
> code:
>
> YAML:
> classes:
> foo:
> var1: foo
> var2: bar
>
> Puppet:
> class foo (
> $var1,
> $var2
> ) { ... }
>
> Now we want to add a new parameter to this class for a certain subset
> of nodes that need new functionality:
> class foo (
> $var1,
> $var2,
> $var3 = 'somedefault'
> ) { ... }
>
> Since we have module versioning, we only need to worry about the new
> nodes getting this version of the class. Unfortunately the YAML that
> drives them is the same. The problem now is that adding the new
> parameter to the YAML will break any machine that uses the old class -
> additional parameters that don't exist in the class interface will
> cause a failure.
>
> We've thought of a few solutions:
> * pass all the parameters as a hash (breaks the interface
> consistency and verification, requires additional hash parameter
> handling)
> * hack Puppet to not complain about additional unexpected parameters
> (breaks the concept of well-defined interfaces)
> * hack Puppet to take an arg* final parameter (an awful combination
> of the above two)
> * version our YAML interfaces in lockstep with Puppet classes
> (removes our ability to benefit from inheritance of common class
> definitions in the ENC)
> * never add new parameters to anything unless we can atomically
> change it everywhere at once
>
this is something that may be worth considering. If you know all of your
possible environments in advance, you could copy your data hierarchy (or
more reasonably branch) and version it to match those environments. This
would ensure that the final resulting data should only match the current
interfaces of the environment.
> * using class introspection, generate class interface YAML that is
> read and used by our ENC instead of using a separate configuration
> specification, store this with the versioned Puppet classes.
>
this would be my vote, the resource_type interface provides all of the
information you need to do this, and its all possible through a well defined
interface.
Since you are generating the environment on the fly, you should have all of
the information that you need to query for mismatches against the current
interfaces. The final data set could be munged and produce warnings if there
are data mismatches.
> I guess this could constitute a fairly solid argument against the
> parameterised class interface benefits I've been arguing for and a
> theoretical vote for Hiera ;) Anyway any thoughts or abuse are welcome!
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
"Join us for PuppetConf <http://bit.ly/puppetconfsig>, September 22nd and
23rd in Portland, OR."
<http://bit.ly/puppetconfsig>
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
