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

Corrective change should use property values directly, bypassing any munging

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Normal
    • Resolution: Fixed
    • PUP 4.6.0
    • PUP 4.6.1
    • None
    • None
    • 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
    • 2
    • Client 2016-08-24
    • Bug Fix
    • 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

            People

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

              Dates

                Created:
                Updated:
                Resolved:

                Zendesk Support