----- Original Message -----
> > !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. > > > From my experimentation, what causes it is the file being actually > absent. not in my case, these files exist, are being managed and are copied out the information just doesnt apply to us now as it relates to some past state that isnt relevant anymore. > > Another way to put this: it appears that when a resource is both > audited and managed the state that is recorded is the state before > the changes due to management are applied. This can happen because > you either intentionally set a managed resource to audit or, as we > found, if audit is set for you as a result of a bug. I dont think its auditing related - I have never enabled auditing and have machines pre 2.6.5 all showing this property in site.yaml and we found others on IRC with the same > > > > 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: > > > I am not sure if this is presently working or not, but I believe it > was a bug previously. > > > > 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. > > > Bingo. I think this is the crux of the matter. > > > We should care for the first problem - but right now I think its a > distraction. > > > I'm not so sure; I think writing the state that was found rather than > the state that was left, if that is what's happening, may also be an > issue we need to look at. if you're auditing, then you're right. if you're not auditing you must remove old auditing data. 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. In this scenario, you'll get notifies and incorrect audit notification, you'll be told audited information has changed rather than the more correct new audited data is gathered. > > > > 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. > > > I'm not sure that the "how it got in there" part is irrelevant (for > instance, I'd like if you could confirm that state.yaml shows > type=>absent on a node that has not been upgraded, and note the yes, all my nodes have it - before upgrading. and people on IRC also has it without upgrading > version), but I agree that a borked state.yaml shouldn't cause a > node to panic and go into spin mode. The question is, how do we > detect it -- that is, how do we distinguish it from "correct" > information? I think we need to know what we record in unaudited state. For example with file if I delete my state.yaml that has these entries all that I see in it then is :checked and :synced. So when you are not auditing this is all the information you should have for file. Anything else should go This is the only way I believe a transition from unaudited -> audited -> unaudited -> audited can ever work reliably as above -- 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.
