The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Feature #6540

Puppet::Transaction::Report should have status to indicate desired noop change

Added by Dan Bode over 3 years ago. Updated over 1 year ago.

Status:Needs DecisionStart date:03/01/2011
Priority:NormalDue date:
Assignee:eric sorenson% Done:

0%

Category:reports
Target version:-
Affected Puppet version:2.6.4 Branch:
Keywords: customer

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

The status is a very useful way to quickly understand what happened in a run. There should be a special status to indicate that although nothing changed, some things wanted to change, but noop was set.

The below example show a run where —noop=true, the final resulting status is ‘unchanged’ I propose that the final result should be noop_changed

notice: Compiled catalog for -etc-puppet-foo-dansmodule-tests-init.pp in environment foo in 0.04 seconds
notice: Finished catalog run in 0.04 seconds
--- !ruby/object:Puppet::Transaction::Report
  configuration_version: 1298730477
  host: mypuppetmaster
  kind: apply
  logs: []
  metrics: 
    time: !ruby/object:Puppet::Util::Metric
      label: Time
      name: time
      values: 
        - 
          - user
          - User
          - 0.000695
        - 
          - total
          - Total
          - 0.000695
        - 
          - config_retrieval
          - Config retrieval
          - 0
    resources: !ruby/object:Puppet::Util::Metric
      label: Resources
      name: resources
      values: 
        - 
          - total
          - Total
          - 1
    events: !ruby/object:Puppet::Util::Metric
      label: Events
      name: events
      values: 
        - 
          - total
          - Total
          - 0
    changes: !ruby/object:Puppet::Util::Metric
      label: Changes
      name: changes
      values: 
        - 
          - total
          - Total
          - 0
  puppet_version: 2.6.5
  report_format: 2
  resource_statuses: 
    "User[dan]": !ruby/object:Puppet::Resource::Status
      change_count: 0
      changed: false
      evaluation_time: 0.000695
      events: []
      failed: false
      file: /etc/puppet/foo/dansmodule/manifests/init.pp
      line: 4
      out_of_sync: false
      out_of_sync_count: 0
      resource: "User[dan]"
      resource_type: User
      skipped: false
      tags: 
        - user
        - dan
        - class
        - dansmodule
      time: 2011-02-26 08:27:57.894180 -06:00
      title: dan
  status: unchanged
  time: 2011-02-26 08:27:57.882869 -06:00

Related issues

Related to Puppet Dashboard - Feature #3535: Display the status of reports from "noop"/audit runs for ... Duplicate 04/12/2010
Related to Puppet Dashboard - Feature #6537: Need to be able to tell if a node is currently "pending" Closed 03/01/2011

History

#1 Updated by Zach Leslie over 3 years ago

  • Status changed from Unreviewed to Accepted

#2 Updated by Anonymous over 3 years ago

I’m not convinced that “status” is the right thing to change here. E.g., I don’t think it makes sense for a noop run to indicate “kind: apply” — that’s plainly incorrect. I’d like to find a better way to make these two properties useful and correct.

#3 Updated by Dan Bode over 3 years ago

I disagree, noop can be both a per run as well as a per resource setting.

#4 Updated by Anonymous over 3 years ago

Yes, noop can be per-run or per-resource, or both. I think we do agree on the problem, just not the solution.

Your proposal is “a special status to indicate that:

  1. nothing changed,
  2. some things wanted to change,
  3. noop was set."

I think this is overloaded, too many things to be indicated by one flag.

From my reading, the “kind” property tells us what kind of run we performed to generate the report. If we do a noop run, we still get “kind: apply.” I think this is factually wrong and should be changed. Setting this to “noop” (or “simulate” as some people prefer) would take care of (3).

For #6537 we also need to know about (2). If we’re indicating “noop” elsewhere then it doesn’t need to be part of the “status” property. “Pending” is the term we’ve been using for this when discussing Blackrock and will be user-facing in that work. What about the same thing here: “status: pending”?

#5 Updated by Dan Bode over 3 years ago

My understanding of status is that it is related to the status of the overall run which is an aggregate of the status of the individual resources.

The status of a run can be in one of 4 states:

  • failed
    • If one resource fails, then a run is in failed state, regardless of the status of the rest of the resources.
  • changed
    • If one resource changed, then a run is in a changed state, regardless of other resources that are in compliance or pending.
  • pending
    • If one resource is pending (but not resources changed or failed), then the run resulted in a pending state.
    • in compliance
  • If all resources are in compliance, then the result is an in compliance state.

Introducing another flag ‘kind’, seems to add another layer of complexity which only gives us visibility in the case where even though we ran in noop, all of the resources are in compliance.

It also adds additional complexity of having to understand the difference between runs that may be in a pending state b/c of an individual resource or b/c of the ‘kind’

#6 Updated by Nigel Kersten over 3 years ago

Dan Bode wrote:

Introducing another flag ‘kind’, seems to add another layer of complexity which only gives us visibility in the case where even though we ran in noop, all of the resources are in compliance.

It also adds additional complexity of having to understand the difference between runs that may be in a pending state b/c of an individual resource or b/c of the ‘kind’

Did you know it’s not a new flag Dan?

http://projects.puppetlabs.com/projects/puppet/wiki/Report_Format_2

"inspect" if this report came from a "puppet inspect" run, "apply" if it came from a "puppet apply" or "puppet agent" run.

I believe Randall is suggesting we make puppet apply --noop and puppet agent --noop produce kind: simulate

#7 Updated by Dan Bode over 3 years ago

Let me try to explain in a different way:

I am aware that this property already exists, but thought it was created specifically for inspect.

I feel that this design decision create unnecessary complexity (although it could be that I don’t understand how it is intended to be layed out)

In my proposed solution, there are 4 states, in the newly proposed solution, there are 7 states.

  • applied/failed
  • applied/chnages
  • applied/noop
  • applied/no changes

  • noop/fail

  • noop/pendingchanges
  • noop/no changes

vs.

  • failed
  • changes
  • noop changes
  • no changes

#8 Updated by James Turnbull about 3 years ago

  • Category set to reports
  • Status changed from Accepted to Needs Decision
  • Assignee set to Nigel Kersten

#9 Updated by Nigel Kersten over 2 years ago

  • Assignee changed from Nigel Kersten to eric sorenson

#10 Updated by Charlie Sharpsteen over 1 year ago

  • Keywords set to customer

Also available in: Atom PDF