On Aug 8, 7: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.
That right there is what I would consider the root of your problem.
Well, combined with the fact that you're using parameterized classes.
Generally speaking, a situation like yours is one of the few for which
I don't much object to parameterized classes, but you do then need to
keep your ENC synchronized with your class interfaces, one way or
another.
> 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.
I'm not a big fan of module versioning, though I appreciate why some
shops would favor it. In this case, your problem would be easier to
address if there were only one version of each module in use at a time
for all your nodes.
> 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)
Yuck.
> * hack Puppet to not complain about additional unexpected parameters
> (breaks the concept of well-defined interfaces)
Double yuck.
> * hack Puppet to take an arg* final parameter (an awful combination
> of the above two)
You have got to be kidding.
> * version our YAML interfaces in lockstep with Puppet classes
> (removes our ability to benefit from inheritance of common class
> definitions in the ENC)
I don't follow you precisely, but you probably do need to do something
along these lines.
> * never add new parameters to anything unless we can atomically
> change it everywhere at once
That sounds something like "[having] only one set of module versions
in use at a time for all your nodes," as I described above. I would
not personally be worried about atomicity in the sense of changing the
configurations already applied, only about atomically changing the
configurations that nodes will get the the next time they request one
from the master. That falls out naturally from having only one
version of the manifest for each class in use at a time.
> * 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.
That seems like a special case of versioning the YAML interfaces in
lockstep with your classes. It should work, but it sounds painful to
set up and maintain.
> 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!
I confess I find it both interesting and surprising that you have run
into problems using parameterized classes in the type of context you
describe, but I guess you have an unusually complex combination of
techniques and goals in play. If have not played with Hiera, but I
like what I've read about it. I would personally account it a design
win to separate nodes' data from their classification, almost as much
as it is a win to separate the data from the classes themselves.
John
--
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.
