On Friday, January 25, 2013 4:05:37 PM UTC-6, Gonzalo wrote: > > > On Sat, Jan 26, 2013 at 1:38 AM, jcbollinger > <john.bo...@stjude.org<javascript:> > > wrote: > >> >> Puppet's architecture does not lend itself to constructing values >> iteratively, and what Hiera brings to the table in that area does not apply >> to the scenario you describe. There are a couple of ways you might be able >> to work around Puppet's constraints there, but before you go that way I >> would suggest that you consider alternative strategies. >> >> Let's start with why you want to add package exclusions to yum.conf via >> multiple modules. I have some ideas of why you might be trying to >> implement such a design, but I'd prefer to avoid guessing. >> > > Hi John, > > Thanks for your reply. > > To be honest, I think in this particular case it's more about trying to > work out how to solve this type of problem, perhaps not necessarily useful > with this exclude line issue. One hypothetical example might be > constructing a "users=" line for some config file and I want to set users > from various modules to construct the line. >
As I said, Puppet's architecture does not lend itself to that kind of thing. In particular, variables and resource properties can be assigned values only once each. Moreover, it is pretty much always a mistake for manifest sets to attempt introspection, as this introduces unneeded extra sensitivity to manifest parse order. Instead, one generally needs to step back and take a different approach. One such approach might be to build up your data in a custom external node classifier (ENC), which provides it to your classes via either a global Puppet variable or a class parameter. Another approach is for modules to declare independent resources instead of collaborating on a single resource. The Concat add-on module, for example, provides a way to implement that for files. You could, in principle, implement similar facilities to serve other purposes. Or you may find that you don't actually need quite the degree of flexibility you describe after all. > > For this exclude line question, I have a class that many nodes "include" > and they all need to exclude one particular RPM to ensure a "yum update" > never upgrades it. These same servers "include" another class, which also > have a package to be excluded. Do you have any ideas on how to solve this > type of problem? > > For packages in particular, you have additional options: 1. In your Package declarations, you can use ensure => 'present' or even ensure => '<package-version>' instead of ensure => 'latest'. That won't prevent a manual package update, but it will prevent Puppet from performing unwanted package updates. The variation where you specify a package version may even get Puppet to revert unwanted manual updates. 2. You really ought to take control of your package repositories. Creating and curating local repositories not only ensures access and reduces demands on your network connection to the outside world, but it also allows you to exercise complete control over what packages are available for installation / update. Depending on your package management system, local repositories may confer additional benefits. For example, on 'yum'-based systems you might consider looking at the yum-priorities and yum-protectbase plugins. 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. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
