On Wed, Mar 2, 2011 at 8:07 AM, R.I.Pienaar <[email protected]> wrote: > Consider this. > > * Today you enable auditing, state.yaml gets the audit properties all is > fine. > * 6 months later you disable auditing - now the audit properties remain but > are > orphaned as we're not purging them > * you now change the desired state of the file in manifests, maybe with a > new mode > * 1 year on you enable auditing. > > Due to the orphaned data you're now comparing the audited state of the first > bullet point - the orphaned data - rather than the last state of the file > since > we didnt record this data in the inbetween time and we didnt purge the > unmanaged > data. We shouldnt record the data when auditing is off cos its a perf hit, > so we > should purge audit data for resources that arent audited.
That's not going to work RI. Consider the case where someone has a fact that varies over time, and causes a resource to flip in and out of being managed *and* audited. This is something people actually do. It's not desirable to trash the state when the resource isn't being managed in such a scenario. In the interests of fixing the current situation, we're aiming for as minimal a set of changes as possible. I'm completely open to us all having a discussion about a slightly longer term approach and even a reinvention for the next major version, as there are clearly some issues around auditing, but the points you're bringing up have been true all through 2.6.x with respect to auditing, it's just that you've been forced to face them since we messed up and turned auditing on for you. -- 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.
