On Mar 22, 2010, at 11:18 AM, Paul Lathrop wrote:
On Sun, Mar 21, 2010 at 10:37 PM, Luke Kanies
<[email protected]> wrote:
Hi all,
I kinda expect blank stares in response to this question, but I'll
do what I
can to both describe what I'm trying to do and to do it in an
interesting
way.
One of the things I've always wanted Puppet to be able to do is to
track
changes of resources without having to actually manage a given
resource.
For instance, I want to be able to say:
file { "/etc/passwd": check => content }
And get an event if that file's content changes, even though I'm not
specifying its content. This specific case actually worked until
0.25, but
only for file content, and even then, only by specifying 'check =>
checksum'. Something in 0.25 broke this, though, so I'm trying to
fix it,
and at the same time make it more general.
I've just converted the checksum property to a parameter (in my
refactor/master/checksum_as_parameter branch, imaginitively
enough), which
mostly just removed the now-non-functional code in the checksum
parameter
and made the rest of the content/checksum/source interaction
considerably
cleaner.
So, life is better but we still don't have out-of-band change
tracking.
It's clear we now need something at the framework level - the
system needs
special support for this, rather than coding it into a parameter -
and I'm
thinking the right answer is to have something akin to noop, but
comparing
to previous state rather than desired state.
This obviously is a structural change and thus, most likely, a
sizeable
change, so I want to make sure I'm on the right track. Unless it's a
straightforward change, I'm not at all sure I'll be trying to get
this done
in the near future -- there's a lot of low-hanging fruit with a
higher-priority -- but I'd like to have it in my head how it will
work,
anyway.
In looking at how noop is implemented -- we just return a noop
event instead
of doing any work -- we should be able to return a similar event
("out_of_band_change" or something). The primary difference is
that, with
this, we have to track the state of every parameter for which we're
doing
this. This has always been the primary purpose of the 'state'
file, and in
general it shouldn't be a huge leap to start tracking this, but
it's worth
pointing out, anyway.
One point worth making is that this definitely has to be done on
top of my
other event work, which means it'd never work in the 0.25 line.
Comments? Fears?
This would be made of awesome. Especially if I could do things like
set up a service that restarts if a file changes outside of puppet
management. I've had to bring things under Puppet management that I'd
rather let the devs control just so I can do this sort of thing.
That's all I've got at the moment...
Yep, that's exactly what you should be able to do.
--
There are three social classes in America: upper middle class, middle
class, and lower middle class. --Judith Martin
---------------------------------------------------------------------
Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
