The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #6548

State.yaml should store state after updates

Added by Paul Berry about 3 years ago. Updated about 2 years ago.

Status:Needs DecisionStart date:03/02/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Affected Puppet version: Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

When a resource is being both audited and managed, the values stored in state.yaml for that resource are the so-called “current values”, which means the values of the resource properties before changes were applied.

This causes an unfortunate scenario:

  1. Assume that a resource is managed, and its state is A, and the user’s manifest calls for state A.
  2. In a later puppet run, the user changes the manifest to call for state B. Puppet changes the state to B, but it still records state A in state.yaml
  3. In the very next puppet run, Puppet examines the state of the machine (B) and compares it to the state in state.yaml (A), and incorrectly concludes that the file has been changed outside of Puppet, so it generates an audit event in the report.

To fix this, we should make sure that when a resource is being both audited and managed, and a change occurs, we update state.yaml with the new state of the resource after the change rather than before it.


Related issues

Related to Puppet - Bug #6310: md5sum reports different md5 than state.yaml Closed 02/14/2011

History

#1 Updated by Ben Hughes over 2 years ago

  • Description updated (diff)
  • Status changed from Accepted to Unreviewed

#2 Updated by Daniel Pittman about 2 years ago

  • Description updated (diff)
  • Status changed from Unreviewed to Needs Decision

I have linked this to what looks like a related ticket: someone found that the MD5 in state.yml didn’t match the observed state on disk; I guess this is the root cause of that.

I have not validated that either this, or the other, ticket are still true.

Someone needs to make a decision about what the state file means, and why it exists, and then from that what the correct behaviour is.

(IMO, if we store state, we should store the pre and post change state.)

Also available in: Atom PDF