R.I. -- >> 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 Thanks. :( I'd been hoping for a different answer but hey, you take what you can get. * 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. > Yep. > > > 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. > > > > > > > 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 > This is a pretty big design issue (and comes down to my "how do distinguish the cases: stale data vs. actual changes?" question), and I'd be surprised if we don't have an answer for it in hand. I just don't happen to know what it is at the moment. We'll need to not only tell if you *are* auditing but if you *were* auditing "on the most recent run" (but we don't want a few minute's dalliance with puppet apply to wipe out all your auditing information either)... Guess what I'll probably be looking into this morning? -- M ----------------------------------------------------------- When in trouble or in doubt, run in circles, scream and shout. -- 1920's parody of the maritime general prudential rule ------------------------------------------------------------ -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
