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
* 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.
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.
