Puppet users - Jan 2010 - Version recipes on a per-application level

A while ago I got some help from here about how to version my puppet
recipes. The solution was to generate an /etc/puppet.conf file via
puppet to create environments like this:

[v01]
    manifest = /etc/puppet/manifests/v01/site.pp

Now, I want to move control of the puppet recipes to the application
level.

In my puppet_node_classifier, I have some variables that define an
application''s version (which puppet uses to ''upgrade''
an application
from one version to the next):

puppet_node_classifier node
---
parameters:
  myapp_version: "123"

Now, what I would like to be able to do is take that variable and use
it to include puppet recipes. Something along the lines of this in my
site.pp, which doesn''t work:

import "myapp/$myapp_version/myapp.pp"

Can anyone point me in the right direction as to how I might do this
sort of versioning of my puppet recipes?

Thanks,
Pete

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

When I''ve needed to do this, I let the Package type handle version
upgrades and then wrote a custom fact to detect the version that was
installed and adjust the system accordingly.

You could also use node-specific variables or defines to do this.

Trevor

On 01/10/2010 02:32 PM, Pete Emerson wrote:
> A while ago I got some help from here about how to version my puppet
> recipes. The solution was to generate an /etc/puppet.conf file via
> puppet to create environments like this:
> 
> [v01]
>     manifest = /etc/puppet/manifests/v01/site.pp
> 
> Now, I want to move control of the puppet recipes to the application
> level.
> 
> In my puppet_node_classifier, I have some variables that define an
> application''s version (which puppet uses to
''upgrade'' an application
> from one version to the next):
> 
> puppet_node_classifier node
> ---
> parameters:
>   myapp_version: "123"
> 
> Now, what I would like to be able to do is take that variable and use
> it to include puppet recipes. Something along the lines of this in my
> site.pp, which doesn''t work:
> 
> import "myapp/$myapp_version/myapp.pp"
> 
> Can anyone point me in the right direction as to how I might do this
> sort of versioning of my puppet recipes?
> 
> Thanks,
> Pete
> 
- -- 
Trevor Vaughan
 Vice President, Onyx Point, Inc.
 email: tvaughan@onyxpoint.com
 phone: 410-541-ONYX (6699)

- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktKSCYACgkQyWMIJmxwHpRt6wCeOMds18e4DBylLSIYaueOINT1
g3sAn3uXIC+mgnHyWXV4Uz7pg7PXorfV
=FN90
-----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.

hello,

----- "Trevor Vaughan" <tvaughan@onyxpoint.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> When I''ve needed to do this, I let the Package type handle version
> upgrades and then wrote a custom fact to detect the version that was
> installed and adjust the system accordingly.
> 
> You could also use node-specific variables or defines to do this.


I have a define:

define pt::package() {
        package{$name: 
            ensure => extlookup("${name}_pkg", "present")
        }
}

It uses extlookup[1] so it means using the extlookup data I decide that a
certain environment/country/operating system etc have different versions from
others, makes it easy to stage deployments through environments.

Also means in some machines I can uninstall screen for example while on a
certain client machines I can install it.


[1] http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php

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

Hmm, I''m not sure this accomplishes what I''m looking for. I
already
have control over what versions get installed on which servers (via a
puppet_node_classifier tied to a database).  Let me go into a bit more
detail. Maybe what you suggest applies, but I''m not seeing it quite
yet. Thanks for your help, I appreciate it.

Here''s a simplified version of my current setup (here, using rpm to do
the install, but in reality under certain circumstances, I also use a
Package def and let yum handle things):

############################
/etc/puppet/manifests/production/site.pp:

import "myapp.pp"

/etc/puppet/manifests/production/myapp.pp:

exec { "install-myapp":
    command => "/bin/rpm -e --nodeps --allmatches myapp ; /bin/rpm
-hiv $rpm_repo/myapp-$myapp_version.x86_64.rpm",
    unless => "/bin/rpm -q myapp-$myapp_version"
}
############################

My puppet_node_classifier populates $myapp_version from a database. If
the desired version is installed, it does nothing, otherwise it
removes all versions of myapp and installs the desired version. To do
an upgrade, I change the database so that a new $myapp_version comes
out of my puppet_node_classifier for a particular set of servers.

What I would like to do is give the developers control over myapp.pp,
so that if they want to add a package dependency or a symlink or a
cronjob or whatever they want to the puppet, they can. So something
like this, if it were possible:

############################
/etc/puppet/manifests/production/site.pp:

import "myapp/$myapp_config/myapp.pp"

/etc/puppet/manifests/production/myapp/$myapp_config/myapp.pp (same as above)
############################

In this scenario, both $myapp_config and $myapp_version would be
populated by my puppet_node_classifier, and
/etc/puppet/manifests/production/myapp would be automatically pulled
from revision control. So if a developer has a current $myapp_config
of 10 and wants to add a new puppet recipe rule, he goes into our SVN
repo and adds config 11 and then changes the database behind the
puppet_node_classifier so that the next time puppet is run on a node
where config 11 has been active, the puppet rules in
/etc/puppet/manifests/production/myapp/11/myapp.pp get run instead of
/etc/puppet/manifests/production/myapp/10/myapp.pp.

This doesn''t seem to be the right approach, though, because
''import
"$foo/myapp.app"'' doesn''t seem to be allowed. But
what I ultimately
want is to have dynamic control over the puppet recipes themselves.

Hopefully this explains a bit better. Thanks again for your help!

Pete

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

As a followup (this is 0.25.1 by the way), I verified that what I was
trying does not work:

In site.pp if I do this:
import "0.2/tester.pp"

the rules in tester.pp execute, but if I try to use a
puppet_node_classifier populated variable, it does not:
import "$admin_config/tester.pp"

No file(s) found for import of ''$admin_config/tester.pp''

It seems that the $admin_config variable is not getting interpreted
prior to the import.

Now, I certainly *could* have my site.pp dynamically generated. But
then that means that I would need to run puppet on my puppetmaster to
generate the site.pp before running puppet on my node.

Pete

On Sun, Jan 10, 2010 at 5:22 PM, Pete Emerson <pemerson@gmail.com>
wrote:
> Hmm, I''m not sure this accomplishes what I''m looking for.
I already
> have control over what versions get installed on which servers (via a
> puppet_node_classifier tied to a database).  Let me go into a bit more
> detail. Maybe what you suggest applies, but I''m not seeing it
quite
> yet. Thanks for your help, I appreciate it.
>
> Here''s a simplified version of my current setup (here, using rpm
to do
> the install, but in reality under certain circumstances, I also use a
> Package def and let yum handle things):
>
> ############################
> /etc/puppet/manifests/production/site.pp:
>
> import "myapp.pp"
>
> /etc/puppet/manifests/production/myapp.pp:
>
> exec { "install-myapp":
>    command => "/bin/rpm -e --nodeps --allmatches myapp ; /bin/rpm
> -hiv $rpm_repo/myapp-$myapp_version.x86_64.rpm",
>    unless => "/bin/rpm -q myapp-$myapp_version"
> }
> ############################
>
> My puppet_node_classifier populates $myapp_version from a database. If
> the desired version is installed, it does nothing, otherwise it
> removes all versions of myapp and installs the desired version. To do
> an upgrade, I change the database so that a new $myapp_version comes
> out of my puppet_node_classifier for a particular set of servers.
>
> What I would like to do is give the developers control over myapp.pp,
> so that if they want to add a package dependency or a symlink or a
> cronjob or whatever they want to the puppet, they can. So something
> like this, if it were possible:
>
> ############################
> /etc/puppet/manifests/production/site.pp:
>
> import "myapp/$myapp_config/myapp.pp"
>
> /etc/puppet/manifests/production/myapp/$myapp_config/myapp.pp (same as
above)
> ############################
>
> In this scenario, both $myapp_config and $myapp_version would be
> populated by my puppet_node_classifier, and
> /etc/puppet/manifests/production/myapp would be automatically pulled
> from revision control. So if a developer has a current $myapp_config
> of 10 and wants to add a new puppet recipe rule, he goes into our SVN
> repo and adds config 11 and then changes the database behind the
> puppet_node_classifier so that the next time puppet is run on a node
> where config 11 has been active, the puppet rules in
> /etc/puppet/manifests/production/myapp/11/myapp.pp get run instead of
> /etc/puppet/manifests/production/myapp/10/myapp.pp.
>
> This doesn''t seem to be the right approach, though, because
''import
> "$foo/myapp.app"'' doesn''t seem to be allowed.
But what I ultimately
> want is to have dynamic control over the puppet recipes themselves.
>
> Hopefully this explains a bit better. Thanks again for your help!
>
> Pete
>
-- 
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 take it back, I can''t have the site.pp dynamically generated via
puppet, because potentially I need it to be different for each server.

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

Okay, here''s a proposed solution, what do you think?

In site.pp:
import "myapp/*/myapp.pp"

In myapp/123/myapp.pp:
if ($myapp_config == ''123'') {
     // recipes go here
}

In this way, all different myapp.pp files get imported, but only the
rules inside the conditional for the desired version get executed.

Still feels a bit hacky, but I think it will work.

Pete

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

Does myapp have a module?

If it does, I would suggest the following:

node foo {
  $myapp_ver = ''123''
  include "myapp"
}

- - /etc/puppet/modules/myapp/manifests/init.pp -

class myapp {
  import "ver/*.pp"
}

- - /etc/puppet/modules/myapp/manifests/ver/123.pp -

if ( $myapp_ver == ''123'' ) {
  // Do the rest of the module
}


This keeps everything nicely logically separated.

However, if you have a lot of versions with commonalities, you may want
to use inherited classes off of ''myapp'' and do something like
the
following in your node:

$myapp_ver = ''123''

case $myapp_ver {
    ''123'': { include "myapp/123" }
    default: { include "myapp/base" }
}


Trevor


On 01/10/2010 06:11 PM, Pete Emerson wrote:
> Okay, here''s a proposed solution, what do you think?
> 
> In site.pp:
> import "myapp/*/myapp.pp"
> 
> In myapp/123/myapp.pp:
> if ($myapp_config == ''123'') {
>      // recipes go here
> }
> 
> In this way, all different myapp.pp files get imported, but only the
> rules inside the conditional for the desired version get executed.
> 
> Still feels a bit hacky, but I think it will work.
> 
> Pete
> 
- -- 
Trevor Vaughan
 Vice President, Onyx Point, Inc.
 email: tvaughan@onyxpoint.com
 phone: 410-541-ONYX (6699)

- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktKfNMACgkQyWMIJmxwHpTM3ACeLC/RiVLtCC60dJaaqHl7DT3B
3dIAoJi6B9yRtYcW2s7dN0RYHk7nvGwB
=uyYs
-----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.