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.
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.
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
}
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.
On Wednesday, January 21, 2015 at 1:38:23 PM UTC+1, Erik Dalén wrote:
>
> Note that you can also just put the standard classes (and variables)
> directly in the top scope. No real need to encapsulate them inside a node
> scope (unless you are overriding the value of facts in the manifest, but
> that seems like a pretty bad idea anyway).
>
> A minor difference is also that resources that are inside a node scope
> will automatically get tagged with the certname of the node, but resources
> and classes in top scope won't. But that automatic tagging is mostly
> useless and a waste of space in PuppetDB IMO.
>
>
>
>
> On Mon Jan 12 2015 at 2:56:06 PM jcbollinger <john.bo...@stjude.org
> <javascript:>> wrote:
>
>>
>>
>> On Friday, January 9, 2015 at 3:34:41 PM UTC-6, RIlindo Foster wrote:
>>>
>>> It seems you are using this as a way to classify nodes. Your best option
>>> is to use an ENC (Foreman or Hiera) to classify your nodes, ideally using
>>> the roles and profiles pattern to abstract your modules.
>>>
>>>
>>
>> I strongly disagree. If you don't otherwise need (or want) an ENC, then
>> this is not a good reason to start using one. Changing the default node to
>> a class and 'include'ing it, as Peter suggested, is much easier, and mostly
>> equivalent to node inheritance. If you use node-scoped variables in the
>> (original) default node, however, then you have more work to do any way
>> around.
>>
>>
>> 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 puppet-users...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/d657abc7-35ba-4c88-84fb-0f714853aa69%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/puppet-users/d657abc7-35ba-4c88-84fb-0f714853aa69%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5fe91224-7062-4529-b95a-3e62e59128b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
