On Wednesday, January 21, 2015 at 11:36:25 AM UTC-6, Alessandro Franceschi
wrote:
>
> Given that:
> - I've used nodes inheritance with profit for years, in the past
> - Now I mostly prefer a nodeless setup (with or without ENC)
> let me spam the list with a fragment of my book Extending Puppet on the
> topic, as it contains some (controversial?) points of view I'm curious to
> hear opinions about (note: it was written before knowing about Puppet4
> removal of nodes' inheritance, so now, I would not use it in any case) :
>
> Node inheritance done right
>
> Node inheritance has a bad reputation. All the Puppet books around, even
> the ones of a giant like James Turnbull, and the official Puppet Labs
> documentation describe it as a bad practice, and this puzzles me, as I
> had successfully used this approach for years.
>
Me, too. I'm sad to see it go, though I won't be too greatly
inconvenienced.
> The main problem, I think, has been a documentation issue, as it's not
> well explained to users that node inheritance makes sense when used to
> assign variables, but it is dangerous when used to manage class grouping.
>
I think the main issue is not so much documentation, but naming / keyword
choice. The actual behavior of Puppet node inheritance is reasonably well
documented, and I have used it successfully for class grouping for years.
The concept of inheritance and the word "inherit[s]" don't very well fit
the actual implementation of node inheritance in Puppet (<4), however.
Despite Puppet's documentation, some people make wrong assumptions about
node scopes when inheritance is involved. I think this tends to occur
where their thinking is colored by experience with the OO concept of
inheritance (and this is one aspect of a larger problem of Puppet adopting
OO terminology for its own, slightly different, concepts). Specifically,
you get in trouble with node inheritance when you suppose that a child node
can influence anything declared by its parent node, other than via explicit
override.
> Let's see an example of a wrong approach to node inheritance:
>
> node default {
> include general
>
> }
> node 'it' inherits default {
>
> $zone = 'it'
> }
>
> node 'web01.it.example.com' inherits 'it' {
> $role = 'web'
> include role::web
>
> }
>
> The issue in this extremely simplified example is that when Puppet parses
> general, it hasn't set the $role and $zone values, and the result for the
> resources declared in general, depending on them, would probably not be
> what was expected.
>
> When node inheritance is used only to set and eventually override
> variables and not to include classes, none of these problems are present:
>
> node basenode {
> dns_server = '8.8.8.8'
>
> }
> node 'it' inherits basenode {
>
> $zone = 'it'
> $dns_server = '1.2.3.4'
> }
>
> node 'web01.it.example.com' inherits 'it' {
> $role = 'web'
> include site
>
> }
>
The rule there being that only leaf nodes should declare any classes, yes?
That's actually quite nice and sensible, with only one limitation I see: it
is hard to extend the inheritance tree once you decide which nodes are
leaves. In practice, that limitation is probably not a big deal.
Another safe general approach to node inheritance is to altogether avoid
node-scoped variables (along with avoiding resource-like class declarations
in node blocks, but you should do that in any case). With that approach
you can create an insanely complex, multi-level node inheritance tree, with
no worries that you will come to grief from it, even when you later modify
or extend it.
> Now, I would not use this approach anymore, as it requires an include
> line for each node, and it sets variables at node scope. This implies that
> while they can be used in the node's classes, we cannot refer to them
> with a fully qualified name, and so, for example, we cannot use them on a
> Hiera hierarchy.
>
> Still, in situations where an ENC and Hiera are not used and the node
> names are not descriptive, this is a working and effective way to
> identify nodes using the benefits of a hierarchical structure, based on
> inheritance.
>
>
As you might guess from my approach to the issue, I've never been much of a
fan of node-scoped variables in the first place. I particularly don't care
for them as a means to feed data to classes. Although that provides for
very safe use of node inheritance, it also means that I can adapt very
easily to not having node inheritance.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/0e419e5a-fdc4-422c-81e1-e5499e69c455%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
