On Mar 22, 2010, at 7:53 AM, Joe McDonagh wrote:
Luke Kanies 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?
I didn't know this stopped working for the file type. I think I use
that trick somewhere...
I discovered it when bragging to a customer that we could do it, then
I (foolishly) actually tested it, and lo and behold not any more.
Obviously not a critical feature for most people, since no one else
had noticed.
--
SELF-EVIDENT, adj. Evident to one's self and to nobody else.
-- Ambrose Bierce
---------------------------------------------------------------------
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.
