On Tuesday, September 18, 2012 1:36:53 PM UTC-5, Philip Brown wrote:
>
> [yes, this is a reply to an OOOLD message. sorry :) I think it's still
> useful]
>
> This is regarding a construct that I suggested to the list back in May,
> and still haven't found anything better for my purposes.
> So, I'm fleshing out the implementation details for people a bit more.
> [...]
> In site.pp, have, as pretty much the only line,
>
> include "autohost::$hostname"
>
> Then in modules/autohost/manifests/yourhost.pp, have contents of
>
> class autohost::yourhost {
> # Whatever-you-want-here
> }
>
>
I think that's just fine. Though no one would know from the responses you
received before, I think some people do pretty much what you're describing.
The main disadvantage I see is that you need a class for every host,
whereas with node declarations you can match nodes to declarations via
regexes, assign multiple node names and regexes to the same node
declaration, and fall back to a default node. If you're not interested in
doing any of those things, and if having one class per node does not
present a scaling problem for you, then it sounds good to me.
Another way you could approach this might be to convert your node
declarations to Hiera YAML files, and use hiera_include() to assign them to
nodes in place of including "autohost:$hostname". Your hiera hierarchy
would have a level based on %hostname, which is where the per-node files
would be pulled in.
The hiera approach has the advantages that you don't necessarily need a
separate file for every node, that you can easily implement shared
defaults, and that you can classify based on more criteria than just
hostname, if you desire. It has the disadvantages that you cannot specify
class parameters that way (if you are unwise enough to use parametrized
classes), and that you cannot set node variables. The latter is mitigated
by the ability to simply look up node data via hiera as well, and the
former will be mitigated in Puppet 3 by the integration of class parameter
resolution with hiera.
Note, however, that there are security implications to using facts instead
of node identities to classify nodes. Node declarations are matched to
client SSL certnames, and it is only a convention that these are normally
the same as the hostname. If an existing client node is subverted then it
can be made to report whatever facts the attacker wants to the puppet
master, and if the master relies on those to classify nodes, then the
attacker can steal the configuration of any node (possibly including
sensitive information). With node declarations, control of one client does
not confer access to the configuration of other clients.
>
> Now to address an older question,
>
>
> On Wednesday, May 2, 2012 6:44:45 PM UTC-7, denmat wrote:
>>
>> Hi,
>> ...
>>
>> This all sounds like a lot of work to me. How do you intend to manage
>> changes that effect 300 nodes?
>>
>
> Very easy. Presuming that there is something these 300 nodes have in
> common; you make a shared base class for them.eg:
>
For what it's worth, that is a misuse of class inheritance unless you are
overriding parameters of a resource inherited from the base class. (That
might be just what you wanted in some cases, however.) Where you're not
overriding, it's better to simply 'include', much as you describe for node
subgroupings.
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/-/ES71pNhTGvEJ.
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.
