On 15.09.2010 16:44, Marc Zampetti wrote:
So does this mean that I need a new intermediate class for every
possible version of the package? Just relying on using the "latest" is
REALLY BAD in production. It means that I can NEVER know for sure that
when I re-build a host that it is in the EXACT state I defined it as.
You have to remember I'm operating in an an environment were we DO NOT
let Red Hat do updates whenever it wants, and Puppet is not running in
daemon mode. We only approve OS updates on a patch by patch basis, and
only apply changes when we are ready to apply them.
Please don't tell me "that is a bad thing to do". First, I completely
disagree. I don't know how many times I've been burned badly because
Red Hat decided to "fix" something that broke my app. The whole point
of Puppet is that ensure me that the host is in the exact state I want
it to be. And yes, if I have 1000 applications, I know I will need to
update the version of the package 1000 times, since I cannot simply
upgrade all applications all at once. For every upgrade, I have to
test and validate the changes, no matter how small.
I have a lot of hosts, and have to support a lot of different versions
of a packages across those hosts. While I am not trying to support
multiple versions of a package on a single host, I at least have to be
able to specify for a given module/class what version to use. And
telling me I have to manage that at the node level seems
counter-intuitive as well. The whole point of Puppet is that the hosts
become somewhat abstracted. I simply define what constitutes an
application, including the versions of things, and then say to Puppet
"make this host be like this". Is everyone really just installing one
app per host, or not caring what version of a package is installed?
Marc
Hmm. Understood, have you thought of using extlookup, that might be best
for your case.
Silviu
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-us...@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.