Disconnect wrote:
> In general, it seems like the best way to handle "must go first"
> bootstrap items like that is with environments. (We haven't gotten
> there yet, but we're moving in that direction.)
>
> New node comes up in environment bootstrap, where there is a generic
> definition and 1 class that just grabs the bare minimum to make
> everything else work. (In our case, that is mostly just the ldap
> configuration so that future runs find the users they want.) Then they
> update the puppet config to move to a new environment, and the new
> environment can ignore all the weird dependencies.
There's another way, which I think is better: tags. Add the metaparameter
'tag => "bootstrap"' to those resources that need to be set up first,
and set 'tags = bootstrap' in puppet.conf. Also add an augeas resource
that changes puppet.conf to 'tags =', and add 'tag => "bootstrap"' to
that resource as well.
A variation of the above is to not run puppetd in its normal daemon
mode. Instead run it from cron, using the command
puppetd --tags=bootstrap --onetime; puppetd --onetime
And don't have any tags setting in the config file at all. This is
what I use. That way, if I in the future add some more resources
that must be run before everything else, those too will be run in
the right order.
The advantage of using tags instead of environments for this, is
that you don't need to maintain two separate sets of manifests.
And you can use environments for testing, production, and so on,
instead of "wasting" that feature on ordering.
/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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
