On Monday, October 15, 2012 9:49:38 AM UTC-5, R.I. Pienaar wrote:
>
>
>
> ----- Original Message -----
> > From: "jcbollinger"
> > To: puppet...@googlegroups.com <javascript:>
> > Sent: Monday, October 15, 2012 3:35:30 PM
> > Subject: [Puppet Users] Re: Puppet 3.0.0 and Hiera
> >
> >
> >
> > On Friday, October 12, 2012 12:10:38 PM UTC-5, Ellison Marks wrote:
> >
> > Not to let this thread go to waste...
> >
> > Since I'm now trying to move away from the hiera functions themselves
> > to the parameter style
> >
> >
> > Why? The ability to achieve separation of data from code while
> > avoiding parametrized classes is one of the greatest advantages
> > conferred by hiera. Every parametrized-style class declaration (not
> > definition) in your manifests is a bug waiting to happen. And if
> > you're not going to use such declarations, then why do you want to
> > spend effort on converting your classes to make it possible?
> >
> >
>
> the param classes integration with hiera in puppet 3 does make it
> worth taking another look at param classes:
>
Indeed, I have taken a second look, and a third, and maybe more. I love
the hiera integration with parametrized classes. It was a fabulous idea,
as it makes it reasonable and safe to use existing parametrized classes
(provided you use only 'include' or 'require' to declare them).
Even with that, however, parametrized classes offer very little of value
over non-parametrized analogs that implement the same hiera-based external
data access. One could argue, perhaps, that there is a documentary
advantage in parametrization, but I think that's poor justification for
introducing functional (so to speak) elements to any class. That's what
comments are for.
>
> The code:
>
> class x($y="hello") {
> notify{$y: }
> }
>
> include x
> include x
>
>
> actually works fine, note this is basically your old school puppet
> syntax, multiple calls to include etc, but with hiera integration
> for the variable key "x::y".
>
Yes, that's great. The problem is that
include x
class { 'x': y => 'goodbye' }
blows up. On the other hand, I understand that
class { 'x': y => 'goodbye' }
include x
works again, which may be even worse (poor consistency).
Of course in that simple example you can just remove either duplicate
declaration, but in real-world examples those declarations are likely to be
in different classes, maybe in different modules. Even if the problem is
known to the site maintainer, it's not necessarily easy to ensure that
those declarations are parsed in an order that will work.
The problem is not the parametrized classes themselves, and certainly not
the hiera integration, but rather the parametrized-style declarations.
Indeed, it was true at least in 2.7 that parametrized-style declarations
could cause you trouble for non-parametrized classes:
class z {
notify { 'z': }
}
class { 'z': }
include 'z' # kapow!
As far as I have been able to determine -- and I've been looking -- Puppet
3 carries over 2.7's biggest problems attending parametrized class
declarations. It's easy enough in Puppet 3 to just avoid using
parametrized-style declarations (yay!), but if you're going to avoid using
them then where's the value in modifying existing classes to support using
them?
> this deals with the dynamic scoping problem, deals with most of the
> things I hate(d) about param classes and gives me magical abilities
> to do overrides where and how I need them.
>
The alternative I would recommend to anyone is this:
class x {
$y = hiera('y', 'hello')
notify{$y: }
}
coupled with avoiding parametrized-style class declarations. It solves the
dynamic scoping problem exactly as well as does the parametrized version
does. It is slightly more verbose than the parametrized version, but more
explicit about what's happening.
That's what I gathered the OP's classes looked like to begin with, since he
said he was using the hiera functions. So I ask again, given classes
structured similar to that, why would it be worth the investment in time
and effort to convert them to parametrized classes?
>
> You can still if u wish use the new param classes style of including,
> ENC etc can all supply data just like always.
>
> from a code share perspective this is a big win, simply using param
> classes means your module is forwards and backwards compatible with
> hiera or without hiera.
>
Ok, so there's at least one fair consideration. If you are looking to
write classes that are backwards-compatible with Puppet 2.[67] setups not
augmented with hiera, then parametrized classes are a way to do it. They
may even be the best way. I don't think you do users any favors by doing
so, however; I would prefer to just make my modules depend on hiera, and
let that be a threshold issue for 2.x sites.
Indeed, I personally look at it quite the other way around: hiera
integration makes parametrized classes tolerable. It provides a good way
forward for the many people who wrote and now rely on parametrized classes
despite their shortcomings (which were more prominent before Puppet 3), and
to me that seems by far its most important compatibility dimension.
I would never dream of using parametrized classes in Puppet older than
3.0. Having in hand a class that loads its external data via hiera, and
not personally being interested in encouraging anyone to use
parametrized-style class declarations, I would have no inclination whatever
to convert it to a substantially equivalent parametrized form.
John
--
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/-/gp8--TwX6z8J.
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.
