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.

Reply via email to