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 [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.
