Thank you very much for your detailed reply John. I hadn't looked at
Hiera before, it looks very interesting. On the point of it's not good
to include node/site data in manifests, it's kind of essential in my
eyes to the setup I am trying to implement.
At my company, one server may serve a site which has very different
requirements to another, so I really needed something that was very
flexible. To expand on the structure I outlined in my previous post:
each server has it's own node.pp file. If you need to change something
(e.g. MySQL settings, which will probably the most frequent one that
needs changing), you can simply edit that server's node manifest file.
The great advantage here is that each site's node manifest serves as
documentation of what changes have been made to it. It's also very
easy to read and understand for someone new to Puppet.
>From some quick reading of the Hiera posts on the Puppet Labs blog, I
guess I could simply have a yaml file for each server with overrides
instead of doing it via the node manifest. However, I don't really see
the advantage of this approach, except for it would cut out some of
the clutter in my Puppet modules. The idea of a hierarchical set of
data being considered in line with Facter facts is very interesting
though, especially if I combined it with some custom facts of my own;
I will do some more reading on that.
With the class/definition point, I am wherever possible using classes,
as usually I'm dealing with the nature of a node (e.g. you are a
webserver, database server etc.) The only case I have used definitions
is for these configuration file overrides. So if I'm understanding
your comments on class/definition use properly, I think I'm sort of
taking the right approach to it...
The key concern for me at the moment is flexibility and scalability...
none of my stuff is live yet, and I want to make sure I'm using best
practices before I put it all in place. :)
On Apr 24, 5:13 pm, jcbollinger <john.bollin...@stjude.org> wrote:
> On Apr 24, 9:13 am, Andy Taylor <andytaylo...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Hi,
>
> > I've written a set of Puppet modules to manage servers, but am
> > slightly concerned about the structure I've used as it seems to differ
> > significantly from anything else I've seen in Puppet Forge/elsewhere
> > on the internet.
>
> > I've made extensive use of definitions so that defaults for modules
> > can be overridden in the node manifest for a server. For example:
>
> > node examplenode.example.com {
>
> > include apache
> > include mysql
>
> > define apache::config {
> > listenport => 8080
>
> > }
>
> > define mysql::config
>
> > }
>
> > So in each module, I have a config definition which must be called in
> > each node manifest, even if you don't want to override any defaults
> > (as in the case of MySQL above). I haven't used parametrized classes
> > at all.
>
> > It all works fine,
>
> That it works well is the most important criterion. With that
> said, ...
>
> > but are there any disadvantages to the sort of
> > structure I'm using? Should I be using more parametrized classes
> > instead of definitions?
>
> One problem with using definitions, especially definitions that are
> required to be instantiated for multiple classes to work, is that each
> instantiation of a definition is a separate resource. Each must
> therefore have a unique name among the resources of its type, and each
> will be applied separately. This presents either a management problem
> (who is responsible for instantiating the definition in any given set
> of circumstances?) or an efficiency problem (equivalent definition
> instances are redundantly applied) or both.
>
> Parameterized classes do not present that efficiency problem because
> all classes are singletons. That intensifies the management problem,
> however, because unlike ordinary classes, each parameterized class can
> be declared only once for any given node. In general, few problems
> are best solved by parameterized classes.
>
> You should use defined types only when you need *resources* for which
> there is no native type available. In that case you should know that
> you want resources rather than classes. That might be because nodes
> can have more than one instance of your 'thing', because you want
> support for virtual or exported 'things', or (best) simply because
> your 'thing' is better characterized as something nodes *have* than as
> something that they *are*.
>
> On the other hand, you should use (ordinary) classes where you want
> their singleton nature -- especially idempotency, which is a far more
> useful property than many appreciate. You must also use classes where
> you need your 'thing' to be declared via an ENC (the C is for
> CLASSifier, after all). You should generally use classes where they
> represent an aspect of nodes' type / kind / role / nature, as opposed
> to a tangible thing you can actually manage.
>
> As for default values and value overriding, if your 'things' are a
> better fit for classes than for definitions, then you should be
> looking at external data and Hiera instead of parameterization. Even
> for any definitions you retain, it might be to your advantage to
> define certain default values via external data than to code them into
> your manifests, or even to remove parameters in favor of external
> data. Really, it is best if your manifests contain no node- or site-
> specific data.
>
> 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.
