I apologize if this has been asked before but if it has- my google technique has failed me. If anyone can point me at the right docs I'm happy to dive right in.
While I'm not having any problems with Puppet, I am having some trouble understanding the best practices. Specifically: I have a basenode defined. I also have several different collections of servers and workstations. I've created a class called prodservers, a class called devservers and a class called workstations- each one inherits basenode and is then inherited by specific nodes. Should I be doing this in a class? If so what is the best place to store these class definitions- right now I am using manifests/classes/ workstation.pp and server.pp. Should this be done in a module instead? Putting specific configuration settings in a module (even if it is a module called "workstation" just feels wrong. http://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice specifically says: "Stop using the manifests area to house classes, definitions, etc. Instead, use module exclusively to manage almost every single class, definition, template, file, etc." That would seem to run counter to the way I've done things. What am I missing? I'd like the admin that comes after me to be able to make sense of this deployment. Another question: The sample templates.pp in the best practices page defines a baseclass and then several types of servers. In what case would you define a baseclass instead of a basenode that you inherit? If you have different classes of servers then templates.pp can easily get unwieldy. I'm using templates.pp and just including my server and workstation specific classes. Is there a more sensible way to organize this? Lastly: Was there a technical reason to split out /services/ and /clients/ from the rest of the modules? It seems somewhat arbitrary and makes configuring certain services a little less intuitive (for example: NTP which is included on all servers, but has a different configuration on the NTP master). What's the best practice here? Do people create a subclass that overrides and disables the generic NTP config and substitutes a server config? What's the best way to define a "::disabled" class? The best practices gives openssh::disabled as an example but I'm having trouble understanding how that would work if the openssh class was already added to the generic server class, but needed to be disabled on a specific system. My apologies for the length of the email- I've been having a lot of fun writing recipes for puppet but these questions have been stopping me from going all out with my deployment. I'd like to get it right (or as close as possible) the first time. Thanks, -Don --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
