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