On Thursday, December 20, 2012 10:51:40 AM UTC-6, Matthew Burgess wrote: > > On Thu, Dec 20, 2012 at 4:11 PM, Steve Button > <[email protected]<javascript:>> > wrote: > > OK. If you're trying to apply your resolv class based on the fact > that Apache is installed, I'd recommend resource dependencies (docs at > http://docs.puppetlabs.com/learning/ordering.html): > > apache { 'vhost-title': > parameter => value, > param2 => value, > before => resolv['resolv.conf'] > } > >
Unfortunately, that doesn't address the question. The 'before' and 'require' metaparameters direct the ordering of resources that have been declared, but they do not themselves declare resources. The resources they reference must be declared separately (and those declarations must have already been parsed). This answer does lead toward a general Puppet truth however: it is preferable to tell Puppet how things *should be* instead of asking it to adapt to how things *are*. Thus, if Apache servers should all have your 'resolv' class then your manifests should ensure that nodes you are configuring with Apache also get resolv. > I personally don't like having dependencies ordered that way (I prefer > 'require'), but given your use case of 'I know which servers I want > Apache on, and resolv needs to be put on those same servers' this > seems to be the more natural way of writing your manifest. > Except that the declaration doesn't say that. In fact, a relationship is probably not warranted here at all, because it doesn't matter (probably) in which order the resources are applied to target nodes -- it only matters that nodes that get Apache also get resolv. > > The most flexible way of assigning classes to nodes is via an External > Node Classifier, or ENC. Documentation at > http://docs.puppetlabs.com/guides/external_nodes.html. I think this > is generally considered the 'correct' method, given that manually > updating site.pp is just unworkable in any large(ish) setup. > I think that's overstating it a bit. An ENC is certainly a viable solution, and a lot of people use them, but in some ways they can be a lot more tedious and error prone than well-written manifests. Even if your site uses an ENC, when you have firm configuration rules that can be expressed in Puppet DSL then it is better to express them that way. For example, supposing that class 'resolv' is not parametrized or does not need to be declared with custom parameters (one of which should be your goal), and supposing that you have a class 'apache' with which you configure your apache nodes, all you need to do to ensure that all apache servers have class 'resolv' is put include 'resolv' at the top of class apache's body. Done. > > For your 'I want to assign the class to all servers in XYZ project', > the first question you have to answer is 'how do you define which > servers are in project 'xyz'. If it's hostname based, your ENC has > direct access to that (the ENC script is called with the hostname as a > parameter). If it's some other property of the server, it may already > be available as a facter variable, which are easily obtainable via > calling out to the 'facter' binary in your script. If it's some other > property, you'll have to somehow make that available to your ENC > script. That could be done via a custom fact, which is documented at > http://docs.puppetlabs.com/guides/custom_facts.html. > > All true, but none of it elects an ENC as the best consumer of the data. I'd rate hiera as a particularly good approach for a case such as this one. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/vfhKSbUoSSMJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
