[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:
Duplicate
is duplicated by PUP-6632 Regression when comparing user groups Closed
Relates
relates to PUP-6621 Corrective Change in Puppet 4.6.0 inc... Closed
Template:
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
    containment_path:
    - Stage[main]
    - Main
    - User[foo]
    evaluation_time: 0.033121403
    tags:
    - 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
    events:
    - !ruby/object:Puppet::Transaction::Event
      audited: false
      property: groups
      previous_value:
      - baz
      desired_value: bar,baz
      historical_value: 
      message: groups changed 'baz' to ['bar', 'baz']
      name: :groups_changed
      status: success
      time: 2016-08-19 12:41:22.752746299 -07:00
      redacted: 
      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

 Description   

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.



 Comments   
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.