[PUP-8096] Filtering resources by tag interferes with corrective vs. intentional change determination Created: 2017/03/08  Updated: 2018/02/06  Resolved: 2017/11/23

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: PUP 5.3.4, PUP 5.4.0

Type: Bug Priority: Normal
Reporter: Nick Lewis Assignee: Pieter Loubser
Resolution: Fixed Votes: 0
Labels: scr-candidate-irving
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Template: PUP Bug Template
Epic Link: SCR Platform Fixes
Team: Security, Compliance, & Reporting
Story Points: 5
Sprint: SCR 2017-11-01, SCR 2017-11-15, SCR 2017-11-29
Release Notes: Bug Fix
Release Notes Summary: Puppet will now correctly report corrective vs intentional change if a resource had been previously skipped based on tag filtering.
QA Risk Assessment: Needs Assessment


Reproduction steps:
• Add a new resource to site.pp
• Run puppet agent -t on the node
• Observe that the change is properly marked as intentional
• Modify the resource on disk
• Run puppet agent -t on the node
• Observe that the change is properly marked as corrective
• Modify the resource on disk
• Run puppet agent -t --tags faketag on the node (this can be done before or after the previous step)
• Observe that no change is made
• Run puppet agent -t on the node
• Observe that the change is wrongly marked as intentional

The agent uses a transaction persistence file to store the previous desired state (or actual state? unclear) which it can compare to the current state on the next run. That file seems to only include resources that are actually managed on a given run, so any resource that is skipped due to tags is omitted. That causes the agent to think that every change is intentional the next time around.

I expect this is also broken for resources which are skipped due to failed dependencies, though I haven't tested that.

Comment by Scott Walker [ 2017/10/16 ]

Here's the problem.

Imagine we have 5 resources and so some Puppet runs:

  • Run 1: no tag: resources A B C D E
  • Now modify (say) D outside of Puppet.
  • Run 2: no tag: resources A B C D E
  • D's actual value is identified as changed from the last time we touched D in run 1 and so is corrective.
  • Run 3: with vowels-only tag: resources A E
  • As a result of this run we only have state for A and E. Since we din't touch B C D, they are implicitly assumed to have been deleted. This is the bug.
  • Finally: modify D again outside Puppet.
  • Run 4: no tag: resources A B C D E
  • We have no prior state for D from the last run, and so like any new resource for which we have no prior knowledge we just assume it is intentional. This behaviour is correct I think.

Today, the policy is: “record state for whatever resources we touched and infer the rest should be discarded because they have been deleted from the catalog".

It needs to be: “update state for whatever was touched, discard whatever is explicitly no longer in the catalog, leave the remaining resources alone".

The next step is to scope out how much work it would take to fix.

Thanks Pieter Loubser for the help.

Comment by Scott Walker [ 2017/10/17 ]

Spike proposing a fix: https://github.com/puppetlabs/puppet/compare/master...scottyw:pe21884-support-tags-in-corrective-change?expand=1

Comment by Scott Walker [ 2017/10/26 ]

Nick Lewis If you've time, would you mind taking a look at this one?



Comment by Josh Cooper [ 2017/11/13 ]

Merged to 5.3.x in 3f4e474d085f28d4cf18472ade92b1cdc1731691, master in fbab1ea728a703b540df0100cfab014b3ad27549

Comment by Kenn Hussey [ 2018/01/02 ]

Josh Cooper please provide release notes for this issue, if needed. Thanks!

Generated at Tue Jul 14 20:16:05 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.