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... --Paul -- 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.
