Luke Kanies <l...@madstop.com> writes:
> On Feb 5, 2009, at 8:14 PM, Daniel Pittman wrote:
>>
>> 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?
Hmmmm. My expectation of multiple items with a "last" tag is that they
would behave like any other round of resources: unordered, unless they
had internal dependencies.
exec { "example 1": last => true }
exec { "example 2": last => true, require => Exec["example 1"] }
exec { "example 2": last => true }
That would, I would anticipate, run example 2 after example 1, but
without defined order to example 3.
Perhaps something like "weight" would be more appropriate, to allow a
resource to be pushed around in the graph?
exec { "example 1": weight => 100 } # 100 is standard
exec { "example 2": weight => 200 } # gonna happen later...
exec { "example 3": weight => 150 } # half way between...
exec { "example 4": weight => 300, before => Exec["example 1"] }
In that, I would imagine that the resolver would run example 4 prior to
example 1, but might emit a warning about the constraint being
roughed-up, perhaps?
> 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 think the biggest problem, though, is that I don't have a formal
notion of what I want to achieve, just an informal desire to integrate
with a bit of software in a specific fashion.
I might, perhaps, think a bit more about this and see if I can make some
more concrete proposal about the whole thing...
Regards,
Daniel
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
