Luke Kanies wrote: > 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'.
Ah, yes O:-) > It should have been mentioned in the change log and release notes and > stuff. It's neither mentioned in the release notes (http://reductivelabs.com/trac/puppet/wiki/ReleaseNotes) nor the CHANGELOG (http://projects.reductivelabs.com/projects/puppet/changelog). I've checked now. > 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. If I read the docs correctly, it's just output from a script, so one can get any local "release state" tag/version which makes sense locally. 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 -~----------~----~----~----~------~----~------~--~---
