Bug #6548
State.yaml should store state after updates
| Status: | Needs Decision | Start date: | 03/02/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | - | |||
| Affected Puppet version: | Branch: | |||
| Keywords: | ||||
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:
- Assume that a resource is managed, and its state is A, and the user’s manifest calls for state A.
- 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
- 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
History
#1
Updated by Ben Hughes over 1 year ago
- Description updated (diff)
- Status changed from Accepted to Unreviewed
#2
Updated by Daniel Pittman over 1 year 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.)