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
On 9/14/10 5:42 PM, Silviu Paragina wrote:
Skipping the practices part, you can achieve the final objective by
adding another level of inheritance (apache-app-ver-2....) and the two
classes in the end would inherit from, or include, this new class.
Logically if there is any reason for apache having the same version in
both application 1 and 2, that "reason" with it's specific
configuration should go in a common manifest. Your logic for naming
the intermediary class should then become apache-app-reason. If there
is no reason I don't see why you aren't using latest/installed, with
or without a private repository.
IMHO in puppet you should specify what an application needs, not
everything down to the version, or at least set the version somewhere
common to all the classes that need to use it. Think of it this way,
if you get to have 1000 applications, and need to upgrade apache
because of a security flaw you will have to edit that in 1000 places,
instead of a single class or using latest.
A case where this shouldn't apply is virtual boxes, where there is
only one function for the machine, and you might want the version of
every software you use to be fixed.
For how it would be ideal to do it, I'm not sure, I'm waiting for
comments too. :)
Silviu
On 14.09.2010 23:55, Marc Zampetti wrote:
Basically, I'm trying to build modules that implement best practices
(the app-apache module), and then admins that need to build specific
apache instances just create a new module that inherits from the base
class and provides the information they need.
So, admin A wants to build apache server 1, and thus creates
app-apache-server1. They set the version of apache they need, any
other required information (like docroot, etc.), and add anything
else specific to that application.
Admin B wants to build apache server 2, and thus creates
app-apache-server2. They go through the same process as admin A.
Notice, there are no nodes in this discussion. Its all about defining
an application. Then its time to say which nodes that apps will run
on. In this case, I want a single node to run both apps. Whenever I
try to do that with Puppet, I keep getting duplicate errors related
to the package.
All of this assumes that the appropriate coordination has occurred to
make sure that both app definitions. That means that they are both
trying to use the same version of the package, don't conflict with
files or ports, etc.
Also, I think I forgot to mention that I am using puppet 0.25.5.
Marc
On 9/14/10 4:39 PM, Silviu Paragina wrote:
On 14.09.2010 23:12, Marc Zampetti wrote:
I've been banging my head on this all day, and I cannot seem to
figure out how to do it.
I have a package for Apache HTTPd. I want to be able to specify the
exact version of the package to use for a particular installation.
And it is also possible that I want to have two separate modules
install the same package.
So, what I end up with is the following
class app-apache {
package { "apache" : ensure => installed, noop => true }
}
class app-apache-server1 inherits app-apache {
Package["apache"] {ensure => "2.2.15", noop => false}
}
class app-apache-server2 inherits app-apache {
Package["apache"] {ensure => "2.2.15", noop => false}
}
Basically, I have two servers configured. Now, it is possible that
both servers could end up on the same host, depending upon a number
of facters. When that happens, I get an error about not being able
to override the "ensure" method in app-apache-server2 because it
was already overridden in app-apache-server1.
Anyone have any ideas on how to do this? I need to be able to
specify the version I want for a particular class, and that can
change from class to class. I realize that if two different classes
define two different versions and both classes end up on the same
node, I will get errors from YUM. I'm ok with that.
Marc Zampetti
I don't see any way to do what you want directly. But in your
specific case you may add another level of inheritance, that
specifies the version, and inherit both of your classes from that,
and you will get an error from puppet for double override in that
case. You shouldn't feed much into yum as you might get an actual
response in package management...
As an alternative you may get the version from a variable for the
specified class, but this would leave you with somewhat of a
nightmare for double inclusion.
Leaving that aside what are you trying to do? What you are doing
doesn't seem right to me. Any code that uses copy/paste should be
refactored to call that common piece of code instead of the
programmer/admin doing a copy paste of that code.
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.
