Puppet users - Sep 2010 - Specifying version for shared packages

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


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Sep 14, 2010 at 1:12 PM, Marc Zampetti <marc.zampetti@gmail.com>
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
Marc,

We''re doing what your trying to. We''d be screwed without the
ability
to specify a package version. We do:

package foo {
    ensure => "1.21-10-1"
}

Works fine...

Doug.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Sep 14, 2010 at 2:36 PM, Douglas Garstang
<doug.garstang@gmail.com> wrote:
> On Tue, Sep 14, 2010 at 1:12 PM, Marc Zampetti
<marc.zampetti@gmail.com> 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
>
> Marc,
>
> We''re doing what your trying to. We''d be screwed without
the ability
> to specify a package version. We do:
>
> package foo {
>    ensure => "1.21-10-1"
> }
>
> Works fine...
>
> Doug.
>
Sorry... really bad example. Lets do it right this time...

package {
  "foo":
    ensure => "1.21.10-1";
}

Doug

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I don''t think I''ve made my problem clear. The issue is NOT how
to
specify a version for a package. I know how to do that. And I know how 
to use a define to do it as well.

The issue is that if I call the define from two different classes on the 
same node, I get Duplicate errors. I also know how to make the define a 
virtual resource, but then the problem is I don''t know how to pass in 
the version number when I do the realize.

How can I include the same package more then once on a host, with the 
option of specifying the version to install on a module/class basis.

On 9/14/10 5:47 PM, Darren Chamberlain wrote:
> 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
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- "Marc Zampetti" <marc.zampetti@gmail.com> 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
You can use extlookup[1] to handle the versions for you, then you can manage
it outside of your code and just control it in data.

define pkg() {
   $version = extlookup("pkg_${name}", "present")

   package{$name: ensure => $version}
}


class apache::install {
   pkg{"httpd": }
}


That code is configurable per host/dc/country/whatever you want without changing
manifest, just data.


[1] http://docs.puppetlabs.com/references/2.6.1/function.html#extlookup

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

That is an interesting option. One question though, will I still get 
the Dup error if I end up calling the pkg() define twice with the same 
version from two different modules? That seems to be the root of my problem.

Marc

On 9/15/10 9:49 AM, R.I.Pienaar wrote:
> ----- "Marc Zampetti"<marc.zampetti@gmail.com>  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
> You can use extlookup[1] to handle the versions for you, then you can
manage
> it outside of your code and just control it in data.
>
> define pkg() {
>     $version = extlookup("pkg_${name}", "present")
>
>     package{$name: ensure =>  $version}
> }
>
>
> class apache::install {
>     pkg{"httpd": }
> }
>
>
> That code is configurable per host/dc/country/whatever you want without
changing manifest, just data.
>
>
> [1] http://docs.puppetlabs.com/references/2.6.1/function.html#extlookup
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/15/2010 03:57 PM, Marc Zampetti wrote:
>  That is an interesting option. One question though, will I still get
> the Dup error if I end up calling the pkg() define twice with the same
> version from two different modules? That seems to be the root of my
> problem.
you would still get the same problem. Because your problem is: Which
override should win?

cheers pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyQ0zMACgkQbwltcAfKi3/b3ACglqsbk6iZLDKx5PieECspmOyH
VfwAnjaMhGwSqFAOzJ3kTwt5S+CPe8a6
=bN8m
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- "Marc Zampetti" <marc.zampetti@gmail.com> wrote:
> The problem is that I''m trying to do just what you suggest. I have
a
> single class that defines the package and a default version, or just 
> installed. Then I have sub classes that try to override the version.
> So, the base class is my generic "apache" class, and has all the
logic to
> install apache on the host and configure the basics. Then the child 
> classes add the instance specific stuff. As part of that, I need to 
> specify the version to use.

Using my proposed solution, you don''t need all these classes, just
update the data don''t make more classes.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks, I''ll take a look. However, I''m not on 2.6.1, and
don''t plan to
be for awhile. I think I saw reference to your extlookup being available 
for 0.25.5. Where can I find that?

Marc

On 9/15/10 10:15 AM, R.I.Pienaar wrote:
> ----- "Marc Zampetti"<marc.zampetti@gmail.com>  wrote:
>
>> The problem is that I''m trying to do just what you suggest. I
have a
>> single class that defines the package and a default version, or just
>> installed. Then I have sub classes that try to override the version.
>> So, the base class is my generic "apache" class, and has all
the logic to
>> install apache on the host and configure the basics. Then the child
>> classes add the instance specific stuff. As part of that, I need to
>> specify the version to use.
>
> Using my proposed solution, you don''t need all these classes, just
update the data don''t make more classes.
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

2010-09-15 15:36, Marc Zampetti wrote:
>  I don''t think I''ve made my problem clear. The issue is
NOT how to
> specify a version for a package. I know how to do that. And I know how
> to use a define to do it as well.
> 
> The issue is that if I call the define from two different classes on the
> same node, I get Duplicate errors. I also know how to make the define a
> virtual resource, but then the problem is I don''t know how to pass
in
> the version number when I do the realize.
> 
> How can I include the same package more then once on a host, with the
> option of specifying the version to install on a module/class basis.
First of all, Puppet does not handle installing more than one version
of a package on the same node.  Even if the package itself supports it,
like the kernel packages do.  This:

    package {
        "kernel": ensure => "2.6.18-194.11.1.el5";
        "kernel": ensure => "2.6.18-194.11.3.el5";
    }

will give you an error.

If you only need one version of each package installed on each node,
then you can do it using Puppet.  There exists a nice little function
named ''defined()'' which you can use:

    class app1 {
        if ! defined(Package["needed-package"]) {
            package { "needed-package": ensure =>
"17.23"; }
        }
    }
    class app2 {
        if ! defined(Package["needed-package"]) {
            package { "needed-package": ensure =>
"17.23"; }
        }
    }

The problem with this approach, though, is that if you then also do

    class app3 {
        if ! defined(Package["needed-package"]) {
            package { "needed-package": ensure =>
"17.69"; }
        }
    }

and happen to include both app1 and app3 on the same node, Puppet won''t
detect this conflict, and you will instead get a random version installed.
You won''t even be ensured that Puppet will always choose the same
version!
It could conceivably change its mind between two consecutive runs of puppetd,
with the exact same manifests and options to puppetd and puppetmasterd.

There might be some way to get Puppet to detect this kind of conflict, but
I don''t know of any off hand.  Would need to think more about that.


	/Bellman

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- "Marc Zampetti" <marc.zampetti@gmail.com> wrote:
> Thanks, I''ll take a look. However, I''m not on 2.6.1, and
don''t plan to
> be for awhile. I think I saw reference to your extlookup being
> available for 0.25.5. Where can I find that?

There''s a 0.25.x version @ http://www.devco.net/code/extlookup.rb

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

2010-09-15 16:15, R.I.Pienaar wrote:
> ----- "Marc Zampetti" <marc.zampetti@gmail.com> wrote:
> 
>> The problem is that I''m trying to do just what you suggest. I
have a
>> single class that defines the package and a default version, or just 
>> installed. Then I have sub classes that try to override the version.
>> So, the base class is my generic "apache" class, and has all
the logic to
>> install apache on the host and configure the basics. Then the child 
>> classes add the instance specific stuff. As part of that, I need to 
>> specify the version to use.
> 
> Using my proposed solution, you don''t need all these classes, just
update
> the data don''t make more classes.
Just to make clear, your solution is to have Marc write

    define pkg($app) {
        $version = extlookup("pkg_${name}_${app}",
"present")
        package { $name: ensure => $version; }
    }

    class app1 {
        pkg { "needed-package": app => "app1"; }  # Needs
version 10.17
    }
    class app2 {
        pkg { "needed-package": app => "app2"; }  # Needs
version 10.17
    }
    class app3 {
        pkg { "needed-package": app => "app3"; }  # Needs
version 10.23
    }

in his manifests, and then in a separate file (which extlookup() will
look in) write something like:

    pkg_needed-package_app1,10.17
    pkg_needed-package_app2,10.17
    pkg_needed-package_app3,10.23

Right?  But that doesn''t help him, because if he includes app1 and
app2 on the same node, he will get a conflict, even though they want
the same version of "needed-package".

You must have some more mechanism to resolve that, and the only one
I can think of is to used defined().


	/Bellman

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- "Thomas Bellman" <bellman@nsc.liu.se> wrote:
>     define pkg($app) {
>         $version = extlookup("pkg_${name}_${app}",
"present")
>         package { $name: ensure => $version; }
>     }
> 
>     class app1 {
>         pkg { "needed-package": app => "app1"; }  #
Needs version
> 10.17
>     }
>     class app2 {
>         pkg { "needed-package": app => "app2"; }  #
Needs version
> 10.17
>     }
>     class app3 {
>         pkg { "needed-package": app => "app3"; }  #
Needs version
> 10.23
>     }
> 

no, you just write pkg{"needed-package": } once, and then configure
extlookup to give different hosts different versions.


So here''s a recent example, puppet 2.6.1 came out, I have a bunch of
machines I can test on they are all my machines in the states, my extlookup has:

$extlookup_precedence = ["%{fqdn}", "location_%{location}",
"domain_%{domain}", "country_%{country}",
"common"]


common.csv has:

puppet_pkg,0.25.5-1.el5


while country_us.csv has:

puppet_pkg,2.6.1-1.el5


Without changing any code, without fiddling around with any classes or node
blocks or anything all the machines in the US updated themselves to newer puppet
while the rest of the machines stayed where they were.

Once I was happy with the state of those machine, I removed the country_us.csv
and updated common.csv and everything else got updated

So the challenge is thinking how you want to allow for overrides in a way that
makes sense to you and set your extlookup up accordingly.  Then you only ever
need to mention a package once.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

2010-09-15 16:51, R.I.Pienaar wrote:
> ----- "Thomas Bellman" <bellman@nsc.liu.se> wrote:
> 
>>     define pkg($app) {
>>         $version = extlookup("pkg_${name}_${app}",
"present")
>>         package { $name: ensure => $version; }
>>     }
>>
>>     class app1 {
>>         pkg { "needed-package": app => "app1"; }
# Needs version
>> 10.17
>>     }
>>     class app2 {
>>         pkg { "needed-package": app => "app2"; }
# Needs version
>> 10.17
>>     }
>>     class app3 {
>>         pkg { "needed-package": app => "app3"; }
# Needs version
>> 10.23
>>     }
> 
> no, you just write pkg{"needed-package": } once, and then
configure
> extlookup to give different hosts different versions.
Ah, I understand.

But then you instead need to maintain the mapping between which apps
are installed on which nodes in two places: your manifest files, where
you write include statements, and the extlookup data file.  I''m not
Marc, so I don''t know his exact circumstances, but to me it sounds
messy
and not very maintainable.  Unless you generate both from a common
data source...  (And for this purpose, an external nodes tool would
probably count as "generating" the manifest.)


	/Bellman

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- "Thomas Bellman" <bellman@nsc.liu.se> wrote:
> 2010-09-15 16:51, R.I.Pienaar wrote:
> 
> > ----- "Thomas Bellman" <bellman@nsc.liu.se> wrote:
> > 
> >>     define pkg($app) {
> >>         $version = extlookup("pkg_${name}_${app}",
"present")
> >>         package { $name: ensure => $version; }
> >>     }
> >>
> >>     class app1 {
> >>         pkg { "needed-package": app =>
"app1"; }  # Needs version
> >> 10.17
> >>     }
> >>     class app2 {
> >>         pkg { "needed-package": app =>
"app2"; }  # Needs version
> >> 10.17
> >>     }
> >>     class app3 {
> >>         pkg { "needed-package": app =>
"app3"; }  # Needs version
> >> 10.23
> >>     }
> > 
> > no, you just write pkg{"needed-package": } once, and then
configure
> > extlookup to give different hosts different versions.
> 
> Ah, I understand.
> 
> But then you instead need to maintain the mapping between which apps
> are installed on which nodes in two places: your manifest files,
> where you write include statements, and the extlookup data file. 
I''m not
> Marc, so I don''t know his exact circumstances, but to me it sounds
> messy and not very maintainable.  Unless you generate both from a common
> data source...  (And for this purpose, an external nodes tool would
> probably count as "generating" the manifest.)

yeah, I agree it might not be ideal for all uses, it''s just an option
to consider.  I didn''t read all of his thread.

Trying to model complex relationships like this with classes is a nightmare you
either need lots of inheritance that can be hard to read, debug and anticipate
or you need big if/case logic.   For my example use case I''d have to
make a new 2.6 class and go about editing nodes in groups doing a whole lot of
potentially error prone edits when all I really want is a short term way to do a
staged upgrade


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 15.09.2010 18:52, Silviu Paragina wrote:
> Hmm. Understood, have you thought of using extlookup, that might be 
> best for your case.
>
>
> Silviu
>
To clarify, this might just be a brainfart, I''m still thinking about an
elegant solution. :">


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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.