Puppet users - Apr 2014 - Best practice question: Class(es) with client/server config

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)?

One class would mean to set a role (client, server) via Hiera and
distinguish the target configuration via that role. I.e., within
the class one giant if with two completely different target
configurations. Doesn't sound pretty or good style.

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.)

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?

Thanks in advance for any answer,

	Joachim

PS: The distinction of node/role is not relevant in that use case.
That server exists only once, it factually _is_ its own role.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jschrod@acm.org

-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/ljcak0%24j49%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.