On Apr 24, 12:31 pm, Andy Taylor <andytaylo...@gmail.com> wrote: > Thank you very much for your detailed reply John. I hadn't looked at > Hiera before, it looks very interesting. On the point of it's not good > to include node/site data in manifests, it's kind of essential in my > eyes to the setup I am trying to implement.
Unless the setup you're trying to implement is "one with node-specific data in its manifests", you are mistaken. Or perhaps you misunderstand me. I am not at all saying that your manifests should not rely on node- or site-specific data, only that those data do not belong in the manifest files themselves. Instead, put them in an external data source, such as one accessed via Hiera. That's why I mentioned the principle in the first place. > At my company, one server may serve a site which has very different > requirements to another, so I really needed something that was very > flexible. To expand on the structure I outlined in my previous post: > each server has it's own node.pp file. If you need to change something > (e.g. MySQL settings, which will probably the most frequent one that > needs changing), you can simply edit that server's node manifest file. > The great advantage here is that each site's node manifest serves as > documentation of what changes have been made to it. It's also very > easy to read and understand for someone new to Puppet. It is somewhat better for all node-specific data to be associated with nodes' declarations, and for all site-specific data to be in site.pp, than for such data to be spread throughout your manifests. It still presents problems, however. In particular, it's brittle to put the node-specific data into global variable declarations. The only way that can work is to use conditional 'import'ing of the appropriate node file (else different nodes' declarations will clash). 'Import' itself is best avoided as much as possible, though you'd be on the borderline of one of the few reasonable use cases. On the other hand, putting node-specific data into node-scoped variables limits you to either relying on dynamic scoping (which is being phased out) or using those variables only directly inside your node declaration. Using literal node-specific values directly as function, class, or defined type parameters is a bit better, but it requires you to forward those values throughout the rest of your manifests wherever they are needed. That complicates everything, requiring extra parameters, and perhaps even preventing you from using non- parameterized classes in some places. > From some quick reading of the Hiera posts on the Puppet Labs blog, I > guess I could simply have a yaml file for each server with overrides > instead of doing it via the node manifest. Pretty much, yes. > However, I don't really see > the advantage of this approach, except for it would cut out some of > the clutter in my Puppet modules. More than that: 1) It could greatly simplify and clarify some of your manifests. Your node declarations especially would benefit, but reducing parameterization elsewhere clarifies your manifests by focusing attention on the big picture -- roles, features, capabilities -- and away from the details. 2) It can help you obtain the benefits of using classes (where they are appropriate) without requiring class parameterization (which would lose you some of those same benefits). 3) From a change management perspective, separating the data allows you to more easily recognize the nature of any given change. > The idea of a hierarchical set of > data being considered in line with Facter facts is very interesting > though, especially if I combined it with some custom facts of my own; > I will do some more reading on that. > > With the class/definition point, I am wherever possible using classes, > as usually I'm dealing with the nature of a node (e.g. you are a > webserver, database server etc.) The only case I have used definitions > is for these configuration file overrides. So if I'm understanding > your comments on class/definition use properly, I think I'm sort of > taking the right approach to it... It sounds like you are generally doing the right thing, but you did ask about those definitions, and I don't think they're good style. As I said before, however, the most important criterion is that it works well. > The key concern for me at the moment is flexibility and scalability... > none of my stuff is live yet, and I want to make sure I'm using best > practices before I put it all in place. :) I think making your manifests as generic as possible, separating data from manifests, and using a flexible external data source such as Hiera is a win on both flexibility and scalability. I doubt you'll find a consensus on best practices, but I am confident that you will find others who also consider those to be Puppet best-practices principles. 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.
