I do this kind of thing in a few places, for things like different
or specific versions of mysql, tomcat, libraries, and so on. I use
a define to wrap this up, and the declare is called from within the
node defitions. A simplified example of our method:
define install ($version) {
package {
$name:
ensure => $version,
....
}
}
node foo {
install { "apache": version => "2.2.5" }
}
node bar {
install { "apache": version => "2.2.15" }
}
* Marc Zampetti <marc.zampetti at gmail.com> [2010/09/14 16:55]:
> 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
--
XSLT is a failure wrapped in pain. There's no job for which XSLT is
the right tool. If you think you found a job for which XSLT is a good
tool, chances are the job itself is fucked up.
-- masklinn
--
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.
