Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-6628

Corrective change should use property values directly, bypassing any munging

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: PUP 4.6.0
    • Fix Version/s: PUP 4.6.1
    • Component/s: None
    • Labels:
      None
    • Template:
    • Acceptance Criteria:
      Hide

      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
      

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

        Attachments

          Issue Links

            Activity

              jsd-sla-details-panel

                People

                • Assignee:
                  john.duarte John Duarte
                  Reporter:
                  branan Branan Riley
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: