[PUP-6628] Corrective change should use property values directly, bypassing any munging Created: 2016/08/17  Updated: 2016/11/30  Resolved: 2016/11/30

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: PUP 4.6.0
Fix Version/s: PUP 4.6.1

Type: Bug Priority: Normal
Reporter: Branan Riley Assignee: John Duarte
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is duplicated by PUP-6632 Regression when comparing user groups Closed
relates to PUP-6621 Corrective Change in Puppet 4.6.0 inc... Closed
Acceptance Criteria:

It should be possible to apply the two following manifests in sequence without Puppet apply failing with an error, and the report should indicate that it was NOT a corrective change, since the manifest has changed:

group { 'bar':
  ensure => present
user { 'foo':
  ensure => present,
  membership => inclusive,
  groups => ['bar']

group { 'bar':
  ensure => present
group { 'baz':
  ensure => present
user { 'foo':
  ensure => present,
  membership => inclusive,
  groups => ['bar', 'baz']

  User[foo]: !ruby/object:Puppet::Resource::Status
    title: foo
    file: "/home/branan/proj/pl/puppet/test.pp"
    line: 9
    resource: User[foo]
    resource_type: User
    - Stage[main]
    - Main
    - User[foo]
    evaluation_time: 0.033121403
    - user
    - foo
    - class
    time: '2016-08-19T12:41:22.752345544-07:00'
    failed: false
    changed: true
    out_of_sync: true
    skipped: false
    change_count: 1
    out_of_sync_count: 1
    - !ruby/object:Puppet::Transaction::Event
      audited: false
      property: groups
      - baz
      desired_value: bar,baz
      message: groups changed 'baz' to ['bar', 'baz']
      name: :groups_changed
      status: success
      time: 2016-08-19 12:41:22.752746299 -07:00
      corrective_change: false
    corrective_change: false

Story Points: 2
Sprint: Client 2016-08-24
Release Notes: Bug Fix
Release Notes Summary: Corrective change calculation is now more robust when properties have complex munge and validate methods


Currently, corrective change uses the "correct" should readers/writers for property values. Unfortunately, properties may have munge and unmunge implementations that are not symmetrical, and in some cases this can cause both should= and validate to fail for those types.

If we update corrective_change to be a bit more aggressive when inspecting property values, we can avoid the entire munge/unmunge/validate dance, and simply inject data directly into the property in exactly the same form that we pull it out.

This may causes issues if internal representations of data change between versions of properties, but corrective change reporting is already likely to be flaky in those cases.

Comment by John Duarte [ 2016/08/19 ]

Branan Riley, can you provide an acceptance criteria example for this?

Comment by Branan Riley [ 2016/08/19 ]

John Duarte Acceptance criteria added. It is essentially borrowed from the user report in PUP-6632

Comment by John Duarte [ 2016/08/19 ]

Validated using pre-release version of puppet-agent at SHA cd3af7c containing puppet at SHA 738a8d7

Comment by John Duarte [ 2016/11/30 ]

Geoff Nichols, you moved this ticket from 'closed' to 'needs information' yesterday. Can you comment on what the information or course of action you need?

Comment by Geoff Nichols [ 2016/11/30 ]

Apologies, John Duarte, my update was completely unintentional. I'll (re)close this.

Generated at Mon Dec 09 14:12:21 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.