----- Original Message -----
> On Tue, Mar 1, 2011 at 5:28 PM, Markus Roberts
> <[email protected]> wrote:
> > N --
> >
> >> > That is reassuring.
> >> >
> >> > I think if we peel away:
> >> >
> >> > * the "always auditing" bug
> >>
> >> Yes. I believe this is fixed by Jesse's patch you reviewed:
> >>
> >>
> >> https://github.com/puppetlabs/puppet/commit/e3dfe41ce7da108fc345e58c7df8c1576ea951a0
> >>
> >> > * the "audits notify" surprise
> >>
> >> This is a documentation bug. I'll be filing it soon. There's no
> >> code
> >> solution to this, we're not changing behavior.
> >>
> >> > * state yaml will "remember" the always audit bug even after
> >> > it's fixed
> >>
> >> As of 2.6.5 + cherry-pick the referenced commit, we do correctly
> >> overwrite the values in state.yaml
> >
> > I think we always "correctly overwrite" the values, but we also
> > notice when
> > they change. This isn't something that's "been fixed" in a
> > particular
> > version.
> >
> >>
> >> The undesirable behavior is that this causes an event (which can
> >> trigger a notify) as you go from :absent to the correct value.
> >
> > If :absent is there, I believe it was correct (that is, that the
> > file really
> > was absent).
the file wasnt absent. also notice its :type not :ensure.
> >
> > The one case where we have an issue (I believe) is when the file
> > was absent,
> > being manged but not audited, and we update to a new version with
> > Jesse's
> > fix at the same time we start auditing. (Without the fix, it's
> > much worse,
> > as R.I. documented).
>
> all agreed. Thanks for clarifying and tightening the language Markus.
>
> I mis-characterized the situation because I was under the impression
> I'd shown that content changes triggered :absent, not just ...
> absence.
I dont agree.
I think there are 2 things going on, and we're focussing on the wrong one.
INCORRECT STUFF WRITTEN TO STATE.YAML:
something, at some point wrote stuff into state.yaml that is wrong, in
this case:
!ruby/sym type: !ruby/sym absent
for files that were _never_ set to absent. Setting them to ensure => absent
today doesnt result in the same line being written either, I think there's
some combination of properties, source etc that causes this.
with current code I cannot reproduce this, we might have had a bug in the past
that did this my machines have been updated since back in 0.24 days and state
never gets deleted. For all we know we've fixed this bug months/years ago.
The specifics of this bug doesnt matter, its this _kind_ of bug that matters.
Lets ignore this problem for now and focus on the next bit.
WE DO NOT SCRUB INCORRECT THINGS FROM STATE.YAML:
Imagine something writes some bogus info to state.yaml, be it corruption,
software bug, a user messing around or whatever. The origin doesnt
matter.
With auditing disabled we only update some parts of a specific resource
in state.yaml, we do not make sure there isn't bogus stuff in there. So
for example in the case:
"File[/etc/mcollective/ssl/clients/rip.pem]":
!ruby/sym type: !ruby/sym absent
!ruby/sym checked: 2011-03-02 08:59:18.609780 +00:00
!ruby/sym synced: 2011-01-01 21:01:56.182650 +00:00
The file exist, its part of a recursive copy with purge enforced, this specific
file has never been set as ensure => absent - also please note the property
is TYPE not ENSURE. The correct value here is TYPE => FILE not ABSENT.
The :type being :absent is bogus and should not be there. During a normal
run with auditing disabled it should not care for this property and the fact
that we do not care for it should be enforced by removing it.
As it stands we are effectively orphaning this data, never updating it,
never verifying it and never cleaning it.
I imagine something like have a hash of file properties from state.yaml
and you're just updating the checked and synced ones then writing out
what is there unchanged. What I think we should do is clear the hash for
the file and make new values then save it. We should do this in both
audit and unaudited mode so that we remove stale information about a managed
file from the state.yaml.
The impact of this is that as soon as a user changes the resources into a
state where puppet _does_ care for this property - by enabling auditing -
the information in there is wrong, doesn't reflect current state and causes
audit events to fire in error.
We should care for the first problem - but right now I think its a distraction.
The how that :type got in there doesnt matter right now what matters is a few
people on IRC confirmed they have similar bogus data in their state.yaml and
so we should focus on the 2nd issue and that is how do we make puppets handling
of state.yaml more robust so that old bugs that dumped unexpected or
incompatible
data into it doesnt impact new versions causing them to send unexpected
notifies.
--
R.I.Pienaar
--
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.
