On Oct 5, 2009, at 9:05 AM, David Schmitt wrote: > > Luke Kanies wrote: >> On Oct 4, 2009, at 11:45 PM, David Schmitt wrote: >> >>> 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. >> >> The module version doesn't help you there, any more than the >> configuration version in 0.25 does, because all you know is what part >> of the config says a given fix should happen, not whether that config >> has changed or the local state has. >> > > Without wanting to go into to much local details, Dan has quite the > intelligent report processor, so he should be able to tell whether his > config has changed. Which should give you the "99%" I spoke of. > > You seem to imply that that's already possible with 0.25? I seem do > have > missed that. Any pointers to docs?
What are these 'docs' you mention? :) http://reductivelabs.com/trac/puppet/wiki/ConfigurationReference Look for 'config_version'. It should have been mentioned in the change log and release notes and stuff. Basically, you tell Puppet how to get the version of your config repository (note it's the whole repo, not per-module), and that version gets attached to every resource and every log. -- It is said that power corrupts, but actually it's more true that power attracts the corruptible. The sane are usually attracted by other things than power. -- David Brin --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
