Luke Kanies wrote: > On Oct 4, 2009, at 5:17 PM, Dan Bode wrote: > >> I wanted to toss a possible use case into the mix: >> >> If puppet had some internal knowledge of module versions, it could >> provide puppet events some awareness about when puppet source code >> changes. >> >> This could be useful in differentiating between events that occurred >> as a result of a new version of a module versus random events >> (events not related to source code changes in the module are >> probably more important) > > It would, at the least, be a bit of metadata you could add to the > configuration changes, in addition to the overall repository version > (which would begin to have a bit less meaning if people are keeping > most modules outside the main repo). > > You're more talking about a three-way merge operation (current state, > desired state, previous state), which also needs to be supported but > (I think) is a different feature.
From my understanding, Dan wants to distinguish in his reports between events that were caused by a change in the manifest and events that were caused because something (or someone) happened to the system (like a service dying, or a manual change by an unenlightened individual). (Ab-)Using the module version for this is a cheap way to get 99% there. the last 1%, that is changes that were made immediately before the puppet run with the new module version, can probably only caught if you also have the last applied catalog too. Then you can see whether the current state is what was applied in the last run. Regards, DavidS --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
