On Oct 6, 2009, at 12:12 AM, David Schmitt wrote: > > 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.
Hrm. This must be my fault. > >> 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. Exactly. -- However beautiful the strategy, you should occasionally look at the results. -- Sir Winston Churchill --------------------------------------------------------------------- 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 -~----------~----~----~----~------~----~------~--~---
