That'll work, and not at all a bad design choice. But the parameterised cups wrapper class is ultimately unnecessary - you can just have all nodes include cups::client and make sure that the server(s) also include cups::server in a fashion that suits your general manifest design.
Talking roles/profiles, you'd make sure that the cups::client profile is present in all roles, but that the cups-server role also include cups::server. Do move shared resources to a cups::common class. Cheers, Felix On 04/25/2014 01:49 PM, Antoine Cotten wrote: > I don't pretend to give you best practices here, but I would personally > create one cups class as an entry point, with two (at least) boolean > parameters: client and server. > client defaults to true and server to false, either using class defaults > or Hiera's base hierarchy level. > Then you could imagine having two subclasses cups::client and > cups::server which do the things you want. In your main class, you just > have to call either of them using a conditional statement. > > With this approach you can apply the cups class safely to any node by > default, and override the server boolean just for your CUPS server in > either the Hiera hierarchy or site.pp. > > Toni -- 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/535A566B.4040803%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
