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.
