On Feb 5, 2009, at 8:14 PM, Daniel Pittman wrote:
>
> G'day.
>
> We are currently looking to integrate etckeeper[1] into our puppet
> managed hosts, especially the legacy hosts that are still partially
> under manual control.
>
> etckeeper is, essentially, a wrapper around a VCS for /etc, tracking
> changes in file content.
>
> When I say "integrate" I mean, specifically, that we would like puppet
> to commit any changes using etckeeper after running, to capture all
> the
> changes into the revision history.[2]
>
>
> So, essentially, what I would like is to run an 'exec' command at the
> very end of puppet processing, after *all* other actions are complete.
>
> It there any sane way to express this in the puppet language?
>
> (We do already run puppet from a shell script, so I will integrate
> this
> there if I can't do it within the manifest, but I would rather avoid
> that path if I can...)
I've never been able to come up with a clean way of forcing a given
resource to the end of the graph. We could just implement 'first' and
'last' metaparams, but what happens when you have multiple of them?
Really, if someone has some experience with directed graphs and is
interested in spending a bit of time on Puppet, we could probably come
up with a straightforward way of doing this, but it requires a new way
of specifying relationships plus some skullduggery while building the
graph.
I actually just had an idea for how to fix this:
Currently, the whole resource graph starts with Class[main], and could
even be said to be contained by Class[main]. Given that the resource
graph is a directed acyclic graph, this means that if you specify a
relationship to Class[main], it's either a cycle or a noop, depending
on the direction of the graph.
However, we could add something special that said, if you specify a
relationship to Class[main], it removes your other containment
relationship. This would allow you to say, X resource should happen
before/after the rest of the graph. It would have some limitations,
though.
Take a simple configuration like this:
service { "foo": subscribe => MyResource[stuff] }
myresource { stuff: do => stuff }
define myresource($do) {
exec { "$do $stuff": require => Class[main] }
}
The exec is 'contained by' the 'myresource' instance, so there's an
edge between them. My proposal would sever that edge, thus forcing
the exec to run after the rest of the configuration. But the service
is subscribed to Myresource, with the implication being that it's
actually interested in events from the Exec. In this situation,
you've broken the edge between myresource and the exec, so the service
could never see events cascading that way.
However, it's the closest I've gotten to a solution.
Any comments?
--
SELF-EVIDENT, adj. Evident to one's self and to nobody else.
-- Ambrose Bierce
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
