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