On Thursday, April 24, 2014 7:35:10 PM UTC-5, Joachim Schrod wrote:
>
> Hi,
>
> I've got question about best practice, and am interested in advice
> from you experienced folk.
>
> I have a service where there is one server in my net and many
> clients (actually, all systems are clients): CUPS. In client
> setups, one file has to be changed (client.conf), in server setup
> several (cupsd.conf with policy, several printers are installed).
> On the server, client.conf must not be changed.
>
> Is it better to create 2 clases (cupsclient, cupsserver) or one
> class (cups)?
>
>
It is better to have two classes, as there is essentially no commonality
between the resource to be managed in the one case and those to be managed
in the other. Furthermore, what if you ever wanted the same machine to be
both the server and one of its own clients? I'm not sure whether that is
feasible for CUPS specifically, but as a general manifest design principle
it is quite sound.
To the extent that there is any commonality at all, it should be factored
out into some other class (e.g. Felix's cups::common) that both
cups::client and cups::server declare.
When I use two classes I have the problem how to specify when the
> right class should be declared: What I would like to have is a
> method to declare cupsclient for all nodes, and override that
> declaration for the one node/role that's the server where it should
> be cupsserver. I can't see how I do that properly. (Most class
> declarations are in role files, roles are assigned to nodes via
> Hiera. I don't want to add cupsclient declaration to any and all
> roles except that server role, that repetition is the reason that I
> don't like this approach.)
>
Why *shouldn't* you add cups::client to every role that needs it, and avoid
adding it to those roles that don't need it? Although you currently want
all nodes to be either CUPS clients or a (the) CUPS server, it is
conceivable that you may someday want to manage machines that are neither
(e.g. Windows or Mac clients). And where else do you have in mind to put
the needed declaration anyway?
>
> So I see two approaches, both with deficiencies.
> What approach do I miss?
> How can one of these approaches be changed to get rid of the
> described deficiency?
>
> Can I specify the class name to be declared as a parameter in Hiera?
>
>
Sure you can, and that's a fine way to proceed. (And isn't that what you
are doing already to assign role classes to nodes via Hiera?) For example,
your data might contain this:
common.yaml
----
cups_class: cups::client
my.cups.server.yaml
----
cups_class: cups::server
Then, in some suitable manifest you could write
$cups_class = hiera('cups_class')
include $cups_class
Or you could even shorten that to
hiera_include('cups_class')
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/20bf9e49-bceb-40c9-b9ab-61c2117433cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
