Jira (PUP-7630) "Successful" puppet agent reports hide provider errors

3 views
Skip to first unread message

Paul Schaffer (JIRA)

unread,
Jun 7, 2017, 4:14:03 PM6/7/17
to puppe...@googlegroups.com
Paul Schaffer moved an issue
 
Puppet / Bug PUP-7630
"Successful" puppet agent reports hide provider errors
Change By: Paul Schaffer
Affects Version/s: PE 2017.1.1
Affects Version/s: PUP 4.7.0
Affects Version/s: PUP 4.9.4
Key: PE PUP - 20411 7630
Project: Puppet  Enterprise [Internal]
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Atlassian logo

Josh Cooper (JIRA)

unread,
Jun 7, 2017, 5:09:04 PM6/7/17
to puppe...@googlegroups.com

Past Haus (JIRA)

unread,
Aug 16, 2017, 4:27:04 PM8/16/17
to puppe...@googlegroups.com
Past Haus commented on Bug PUP-7630
 
Re: "Successful" puppet agent reports hide provider errors

Something similar happens if the entire run fails due to a cycle in the graph.

For example...

matthaus@wyclef-2  #> puppet apply -e 'file {"/tmp/foo": ensure => present, require => File["/tmp/foo"],}'
Notice: Compiled catalog for localhost in environment production in 0.08 seconds
Error: Failed to apply catalog: Found 1 dependency cycle:
(File[/tmp/foo] => File[/tmp/foo])
Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz
matthaus@wyclef-2  #> echo $?
1
matthaus@wyclef-2  #> irb
irb(main):001:0> require 'puppet'
=> true
irb(main):002:0> a = YAML.load_file('/Users/matthaus/.puppetlabs/opt/puppet/cache/state/last_run_report.yaml')
=> #<Puppet::Transaction::Report:0x007fd69e135e08 @metrics={"resources"=>#<Puppet::Util::Metric:0x007fd69e135548 @name="resources", @label="Resources", @values=[["total", "Total", 0], ["skipped", "Skipped", 0], ["failed", "Failed", 0], ["failed_to_restart", "Failed to restart", 0], ["restarted", "Restarted", 0], ["changed", "Changed", 0], ["out_of_sync", "Out of sync", 0], ["scheduled", "Scheduled", 0], ["corrective_change", "Corrective change", 0]]>, "time"=>#<Puppet::Util::Metric:0x007fd69e12ef68 @name="time", @label="Time", @values=[["config_retrieval", "Config retrieval", 0.121464], ["total", "Total", 0.121464]]>, "changes"=>#<Puppet::Util::Metric:0x007fd69e12e770 @name="changes", @label="Changes", @values=[["total", "Total", 0]]>, "events"=>#<Puppet::Util::Metric:0x007fd69e12e090 @name="events", @label="Events", @values=[["total", "Total", 0], ["failure", "Failure", 0], ["success", "Success", 0]]>}, @logs=[#<Puppet::Util::Log:0x007fd69e12d230 @level=:err, @message="Failed to apply catalog: Found 1 dependency cycle:\n(File[/tmp/foo] => File[/tmp/foo])\nTry the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz", @source="Puppet", @tags=#<Puppet::Util::TagSet: {"err"}>, @time=2017-08-16 13:04:57 -0700>], @resource_statuses={}, @host="localhost", @time=2017-08-16 13:04:57 -0700, @kind="apply", @report_format=6, @puppet_version="4.10.4", @configuration_version=1502913897, @transaction_uuid="84111aa3-d082-4321-a8d1-91263279d5a7", @code_id=nil, @catalog_uuid="a25e8d10-ffb0-4459-a2ce-324ab72a11e8", @cached_catalog_status="not_used", @master_used=nil, @environment="production", @status="unchanged", @noop=false, @noop_pending=false, @corrective_change=false>
irb(main):003:0> a.exit_status
=> 0

Paul Schaffer (JIRA)

unread,
Aug 16, 2017, 4:35:04 PM8/16/17
to puppe...@googlegroups.com
Paul Schaffer updated an issue
 
Change By: Paul Schaffer
A customer has noticed that they are getting It's possible to get a  successful agent run  reports  report  that on closer inspection include errors  (ticket located here: https://puppetlabs . zendesk.com/agent/tickets/25207).

The For instance, an  error points to a failure with the Chocolatey provider. Because the provider failed out, it did not return a complete list of resources to manage, and the agent run completes successfully on this smaller catalog without raising an alarm.

The issue with the Chocolatey provider was fixed in a later version of that module, however the overall issue There  is  still a problem: there is  no way for an administrator to notice this problem and correct it without drilling down into green agent reports to confirm whether an error has occurred or not. On large scale deployments this solution rapidly becomes unmanageable.

Agent runs need to return some condition when providers fail that highlights that this has occurred. There needs to be a scaleable way to monitor and report on this kind of failure.

Dylan Zeleski (JIRA)

unread,
Aug 16, 2017, 4:58:03 PM8/16/17
to puppe...@googlegroups.com
Dylan Zeleski commented on Bug PUP-7630
 
Re: "Successful" puppet agent reports hide provider errors

We are having the exact same issue as reported originally in the ticket as well as the dependency cycle one. Definitely a major issue with large deployments.

Adam Bottchen (JIRA)

unread,
Aug 16, 2017, 5:15:03 PM8/16/17
to puppe...@googlegroups.com
Adam Bottchen updated an issue
 
Change By: Adam Bottchen
CS Priority: Needs Priority

Owen Rodabaugh (JIRA)

unread,
Aug 24, 2017, 4:59:03 PM8/24/17
to puppe...@googlegroups.com
Owen Rodabaugh updated an issue
Change By: Owen Rodabaugh
CS Priority: Needs Priority Major
CS Impact: This has been a long standing issue. The console should not show a node as "unchanged" when there is an error in the report.

Some customers never look into node reports unless it shows as an error on the front page of the console and due to this they probably won't notice these errors. False negatives are not good.
CS Severity: 3 - Serious
CS Business Value: 4 - $$$$$
CS Frequency: 4 - 50-90% of Customers

Karen Van der Veer (JIRA)

unread,
Sep 18, 2017, 5:31:03 PM9/18/17
to puppe...@googlegroups.com
Karen Van der Veer updated an issue
Change By: Karen Van der Veer
Sprint: Platform Core Grooming

Owen Rodabaugh (JIRA)

unread,
Sep 29, 2017, 1:58:03 PM9/29/17
to puppe...@googlegroups.com
Owen Rodabaugh updated an issue
Change By: Owen Rodabaugh
Method Found: Customer Feedback

Verne Lindner (JIRA)

unread,
Nov 22, 2017, 3:39:05 PM11/22/17
to puppe...@googlegroups.com
This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
Atlassian logo

Adam Bottchen (JIRA)

unread,
Nov 22, 2017, 3:42:02 PM11/22/17
to puppe...@googlegroups.com

Verne Lindner (JIRA)

unread,
Nov 22, 2017, 3:46:03 PM11/22/17
to puppe...@googlegroups.com
Verne Lindner commented on Bug PUP-7630

Eric Sorenson ^^ It would be really lovely to put this thing to bed: on the Enterprise team, we also hear about it quite a bit when we talk to users about console reporting.

Charlie Sharpsteen (JIRA)

unread,
Nov 28, 2017, 7:57:04 PM11/28/17
to puppe...@googlegroups.com

I think we keep playing whack-a-mole with this issue because our fixes are too specific. In the past it was about using a cached catalog. This ticket is about "provider errors".

To put this one to bed, I think we have to go for a general solution: if the logs from the puppet run contain any message at error level, turn the node red in the console or otherwise flag it so that folks know it needs attention.

Josh Cooper (JIRA)

unread,
Nov 28, 2017, 8:57:03 PM11/28/17
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-7630

The whack-a-mole game is because the agent marks the report as failed if and only if any of the applied resources failed. The problem is there are many failure modes before we even start applying resources, e.g. instances, prefetch, loading cached catalog, cycles in the graph, loading providers with gem dependencies, etc.

I don't know that determining report success/failure based on log message error levels will work in all cases, as some failures may not cause an error message to be emitted.

I think a simpler solution may be to assume the report has failed in the beginning and only mark the report as successful if we apply the catalog successfully.

Josh Cooper (JIRA)

unread,
Nov 29, 2017, 1:56:04 PM11/29/17
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-7630

Also due to issues like PUP-1542, it may be that we did try to generate a log event, but that fails, so it never makes it into the report. I think assuming the report failed unless proven otherwise will ensure we don't have false positives in the PE console.

Verne Lindner (JIRA)

unread,
Nov 29, 2017, 2:18:03 PM11/29/17
to puppe...@googlegroups.com
Verne Lindner commented on Bug PUP-7630

Josh CooperCharlie Sharpsteen If assume the report failed unless the catalog applies successfully, how much of a spike in Failed reports could we expect; in other words, would Failed reports become so numerous that their volume would make it difficult for users to know which to investigate first? If so, could we lessen the noise by categorizing Failed reports by type of failures; for example, "fatal failures" (the catalog does not apply), major failures (a high percentage of failure events) and normal failures (don't know how to define 'normal')?

Josh Cooper (JIRA)

unread,
Nov 29, 2017, 2:25:04 PM11/29/17
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-7630

This should only increase the number of failed runs that we're incorrectly reporting as successful, not causing an increase in failed reports in general. The number of newly failed reports should be a small number. I think users would gladly welcome reporting the failure state correctly so that they don't assume everything is ok when it's not, e.g. they think puppet ran 30 mins about, but it really hasn't successfully applied the desired state for weeks.

Verne Lindner (JIRA)

unread,
Nov 29, 2017, 3:16:03 PM11/29/17
to puppe...@googlegroups.com
Verne Lindner commented on Bug PUP-7630

Josh Cooper To your point, they would welcome accurate reporting - no argument there. My question is about identifying and accounting for any usability consequences of the change you're suggesting. From your answer, it seems that excessive reporting noise won't be an issue.

One other consequence that I can think of is current console users will need to know that a Failed report will not always indicate failed resource events, so that if they open a Failed report, and see no failure events, they will understand that they need to look in the log. This seems minor to me, given that users frequently consult both log and events list when looking for information in a report. Charlie Sharpsteen What do you think?

Charlie Sharpsteen (JIRA)

unread,
Nov 29, 2017, 5:45:03 PM11/29/17
to puppe...@googlegroups.com
Charlie Sharpsteen updated an issue
 
Change By: Charlie Sharpsteen
Attachment: pluginsync_failed.png
Attachment: fact_failed.png
Attachment: deprecation_warning.png
Attachment: compile_failed.png

Charlie Sharpsteen (JIRA)

unread,
Nov 29, 2017, 5:47:05 PM11/29/17
to puppe...@googlegroups.com
Charlie Sharpsteen commented on Bug PUP-7630
 
Re: "Successful" puppet agent reports hide provider errors

Assuming the report failed unless the catalog applies correctly is something we already do as reports are initialized to a "failed" state:

https://github.com/puppetlabs/puppet/blob/5.3.3/lib/puppet/transaction/report.rb#L226

So, it seems like there is a bug or regression if catalog application is failing completely but our reports are coming back indicating success. However, I think this approach is too limited even if we fix the regression — the reason being that it allows a successful catalog run to mask serious errors that just happened to be non-fatal to catalog application.

Here's a list of some examples where major errors are logged during different parts of the agent lifecycle, but our Console Overview shows a green status:

  • Catalog applied successfully, but pluginsync failed. This is problematic because we can't be sure the catalog was based on the latest facts and plugins.
  • Catalog applied successfully, but a fact failed to resolve. This is problematic if the fact was critical to compiling a correct catalog.
  • Catalog applied successfully, but it was a cached catalog because compilation failed. This is problematic if we expected to node to receive an up-to-date configuration.

The above list is just three top-of-mind examples I came up with in 15 minutes and is by no means exhaustive. I've attached screen shots showing what the 2017.3.2 Console Overview page shows for node status vs. what the reports page shows is going on under the surface.

Warnings are also something we should think about. These are more numerous and have a higher chance of being red herrings, but Puppet.deprecation_warning is one that we should think about:

  • Catalog applied successfully, but is using deprecated functionality that will break on the next Puppet or Module upgrade.

As Josh mentioned, this all flows from our use of resource status as the indicator of "success" in our node summaries with some finer detail in PE for intentional vs. corrective change. Basically, a visual representation of --detailed_exitcodes. However, the symbology we use for resource status, a "green checkmark", sends a powerful visual signal that "this puppet agent is healthy". Resource status is a major component of agent health, but the examples above show that actually declaring a node a healthy based on resource status alone is not correct.

And that is the heart of this issue: variants of this problem will come back again and again until we broaden our overviews and summaries to present comprehensive information about node health that extends beyond resource status. Otherwise folks will see a field of "green checkmarks" in the console and assume that their agent populations are healthy. Clicking through to reports for hundreds, or thousands, of agent nodes to check whether errors or warnings are being generated isn't feasible.

Charlie Sharpsteen (JIRA)

unread,
Nov 29, 2017, 6:00:12 PM11/29/17
to puppe...@googlegroups.com

Charlie Sharpsteen (JIRA)

unread,
Nov 29, 2017, 6:00:13 PM11/29/17
to puppe...@googlegroups.com
 
Re: "Successful" puppet agent reports hide provider errors

Attached a break_stuff.tar.gz module that contains the above examples.

Josh Cooper (JIRA)

unread,
Dec 6, 2017, 6:33:05 PM12/6/17
to puppe...@googlegroups.com
Josh Cooper updated an issue
 
Change By: Josh Cooper
Fix Version/s: PUP 4.10.z

Verne Lindner (JIRA)

unread,
Dec 7, 2017, 5:19:03 PM12/7/17
to puppe...@googlegroups.com
Verne Lindner commented on Bug PUP-7630
 
Re: "Successful" puppet agent reports hide provider errors

Josh Cooper Charlie Sharpsteen If we want to broaden criteria for a red status to include errors, and some warnings, what do we need to do? Which team would do the work?

Craig Gomes (JIRA)

unread,
Dec 11, 2017, 5:34:06 PM12/11/17
to puppe...@googlegroups.com

Craig Gomes (JIRA)

unread,
Dec 11, 2017, 5:34:07 PM12/11/17
to puppe...@googlegroups.com

Craig Gomes (JIRA)

unread,
Dec 11, 2017, 5:34:07 PM12/11/17
to puppe...@googlegroups.com
Craig Gomes updated an issue
Change By: Craig Gomes
Sprint: Platform Core  Grooming  Hopper

Craig Gomes (JIRA)

unread,
Dec 18, 2017, 12:47:06 PM12/18/17
to puppe...@googlegroups.com
Craig Gomes updated an issue
Change By: Craig Gomes
Sprint: Platform Core  Hopper  KANBAN

Craig Gomes (JIRA)

unread,
Jan 8, 2018, 5:27:03 PM1/8/18
to puppe...@googlegroups.com
Craig Gomes updated an issue
Change By: Craig Gomes
Fix Version/s: PUP 4.10.z
Fix Version/s: PUP 6.0.0

Craig Gomes (JIRA)

unread,
Jan 8, 2018, 5:27:06 PM1/8/18
to puppe...@googlegroups.com
Craig Gomes updated an issue
Change By: Craig Gomes
Sprint: Platform Core  KANBAN  Hopper

Kris Bosland (JIRA)

unread,
Jan 9, 2018, 2:54:04 PM1/9/18
to puppe...@googlegroups.com

Kris Bosland (JIRA)

unread,
Jan 9, 2018, 2:54:05 PM1/9/18
to puppe...@googlegroups.com
Kris Bosland updated an issue
 
Change By: Kris Bosland
Fix Version/s: PUP 6.0.0
Fix Version/s: PUP 4.10.z

Kris Bosland (JIRA)

unread,
Jan 9, 2018, 2:58:07 PM1/9/18
to puppe...@googlegroups.com
Kris Bosland updated an issue
Change By: Kris Bosland
Sprint: Platform Core  Hopper  KANBAN

Josh Cooper (JIRA)

unread,
Jan 10, 2018, 5:42:04 PM1/10/18
to puppe...@googlegroups.com

Josh Cooper (JIRA)

unread,
Jan 10, 2018, 5:44:06 PM1/10/18
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
Fix Version/s: PUP 5.4.0

Josh Cooper (JIRA)

unread,
Jan 10, 2018, 5:44:07 PM1/10/18
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
Fix Version/s: PUP 4.10.z

Josh Cooper (JIRA)

unread,
Jan 10, 2018, 5:47:04 PM1/10/18
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-7630
 
Re: "Successful" puppet agent reports hide provider errors

Note to watchers, we are making an immediate fix for this issue in PUP-8288 to be released in the next 4.10.x release so that we don't report success if we fail to apply the entire transaction. We are planning additional improvements for all of the issues described here in 5.4.0.

Verne Lindner (JIRA)

unread,
Jan 17, 2018, 4:46:05 PM1/17/18
to puppe...@googlegroups.com
Verne Lindner updated an issue
 
Change By: Verne Lindner
It's possible to get a successful agent run report that on closer inspection include errors.

For instance, an error points to a failure with the Chocolatey provider. Because the provider failed out, it did not return a complete list of resources to manage, and the agent run completes successfully on this smaller catalog without raising an alarm.

There is no way for an administrator to notice this problem and correct it without drilling down into green agent reports to confirm whether an error has occurred or not. On large scale deployments this solution rapidly becomes unmanageable.

Agent runs need to return some condition when providers fail that highlights that this has occurred. There needs to be a scaleable way to monitor and report on this kind of failure.


Please add all errors and warnings for consideration as failed run status assignment criteria [here|https://docs.google.com/document/d/1PKLzYYPyPVt0pKS4Fc6r-1BbDAfK8eFOmTICcgT5gQ4/edit?usp=sharing].

Verne Lindner (JIRA)

unread,
Jan 17, 2018, 4:48:04 PM1/17/18
to puppe...@googlegroups.com
Verne Lindner commented on Bug PUP-7630
 
Re: "Successful" puppet agent reports hide provider errors

Josh Cooper That's good news!

Watchers, I linked a document to the description, with errors we need to consider as failed run status assignment criteria. I added Charlie Sharpsteen's suggestions from his comment above. Please add any other warnings and errors you believe should be considered.

Kris Bosland (JIRA)

unread,
Jan 30, 2018, 4:54:03 PM1/30/18
to puppe...@googlegroups.com
Kris Bosland updated an issue
 
Change By: Kris Bosland
Acceptance Criteria: When a provider fails in prefetch:
  1. The agent run should be reported as failed.
  2. Resources that use that provider should be marked as failed and not evaluated.
  3. Resources that depend on resources that use that provider should not be evaluated.
  4. Unrelated resources should still run.

Kris Bosland (JIRA)

unread,
Feb 1, 2018, 4:18:08 PM2/1/18
to puppe...@googlegroups.com

Kenn Hussey (JIRA)

unread,
Feb 5, 2018, 10:36:03 AM2/5/18
to puppe...@googlegroups.com
Kenn Hussey commented on Bug PUP-7630

Kris Bosland please add release notes for this issue, if needed. Thanks!

This message was sent by Atlassian JIRA (v7.5.1#75006-sha1:7df2574)
Atlassian logo

Kris Bosland (JIRA)

unread,
Feb 5, 2018, 12:26:05 PM2/5/18
to puppe...@googlegroups.com
Kris Bosland updated an issue
Change By: Kris Bosland
Release Notes Summary: Providers that fail in prefetch will now cause the resources that use them to fail and not be evaluated.  This will not affect other resources or providers that are not dependent on the failed provider and resources.
Release Notes: Bug Fix

Kris Bosland (JIRA)

unread,
Feb 5, 2018, 1:25:04 PM2/5/18
to puppe...@googlegroups.com
Kris Bosland commented on Bug PUP-7630
 
Re: "Successful" puppet agent reports hide provider errors

Hi Kenn,

I have added release notes, please let me know if you have any feedback.

On Mon, Feb 5, 2018 at 7:36 AM, Kenn Hussey (JIRA) <

Craig Gomes (JIRA)

unread,
Feb 5, 2018, 5:03:04 PM2/5/18
to puppe...@googlegroups.com
Craig Gomes assigned an issue to Eric Delaney
 
Change By: Craig Gomes
Assignee: Kris Bosland Eric Delaney

Eric Delaney (JIRA)

unread,
Feb 5, 2018, 5:59:04 PM2/5/18
to puppe...@googlegroups.com
Eric Delaney commented on Bug PUP-7630
 
Re: "Successful" puppet agent reports hide provider errors

Tested on master SHA=7938d1daae36d9b7f77abeebb771475367e89022 SUITE_VERSION=5.3.3.588.g7938d1d

root@wt9n8bzzrillanz ~]# puppet apply -e 'file {"/tmp/foo": ensure => present, require => File["/tmp/foo"],}'
Notice: Compiled catalog for wt9n8bzzrillanz.delivery.puppetlabs.net in environment production in 0.02 seconds
Error: Found 1 dependency cycle:
(File[/tmp/foo] => File[/tmp/foo])\nTry the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz
Error: Failed to apply catalog: One or more resource dependency cycles detected in graph
[root@wt9n8bzzrillanz ~]# echo $?
1
[root@wt9n8bzzrillanz ~]# find /opt -name last_run_report.yaml
/opt/puppetlabs/puppet/cache/state/last_run_report.yaml
[root@wt9n8bzzrillanz bin]# ./irb
irb(main):001:0> require 'puppet'
=> true
irb(main):003:0> a =YAML.load_file('/opt/puppetlabs/puppet/cache/state/last_run_report.yaml')
=> #<Puppet::Transaction::Report:0x0000000003339278 @puppet_version="5.3.5", @report_format=8, @configuration_version=1517870652, @transaction_uuid="379bb0cd-0cae-49b0-8e64-32343acd1cc6", @environment="production", @status="failed", @transaction_completed=false, @noop=false, @noop_pending=false, @host="wt9n8bzzrillanz.delivery.puppetlabs.net", @time=2018-02-05 14:44:12 -0800, @corrective_change=false, @catalog_uuid="1fe088fb-1766-4025-841b-438c1ab0fde7", @cached_catalog_status="not_used", @metrics={"resources"=>#<Puppet::Util::Metric:0x000000000332d068 @name="resources", @label="Resources", @values=[["total", "Total", 1], ["skipped", "Skipped", 0], ["failed", "Failed", 1], ["failed_to_restart", "Failed to restart", 0], ["restarted", "Restarted", 0], ["changed", "Changed", 0], ["out_of_sync", "Out of sync", 1], ["scheduled", "Scheduled", 0], ["corrective_change", "Corrective change", 0]]>, "time"=>#<Puppet::Util::Metric:0x000000000332d040 @name="time", @label="Time", @values=[["config_retrieval", "Config retrieval", 0.058405578], ["total", "Total", 0.058405578]]>, "changes"=>#<Puppet::Util::Metric:0x000000000332d018 @name="changes", @label="Changes", @values=[["total", "Total", 0]]>, "events"=>#<Puppet::Util::Metric:0x000000000332cff0 @name="events", @label="Events", @values=[["total", "Total", 1], ["failure", "Failure", 1], ["success", "Success", 0]]>}, @logs=[#<Puppet::Util::Log:0x000000000332cfa0 @level=:err, @message="Found 1 dependency cycle:\n(File[/tmp/foo] => File[/tmp/foo])\\nTry the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz", @source="Puppet", @tags=#<Puppet::Util::TagSet: {"err"}>, @time=2018-02-05 14:44:12 -0800>, #<Puppet::Util::Log:0x000000000332c5c8 @level=:err, @message="Failed to apply catalog: One or more resource dependency cycles detected in graph", @source="Puppet", @tags=#<Puppet::Util::TagSet: {"err"}>, @time=2018-02-05 14:44:12 -0800>], @resource_statuses={"File[/tmp/foo]"=>#<Puppet::Resource::Status:0x000000000332bcb8 @resource_type="File", @title="/tmp/foo", @resource="File[/tmp/foo]", @containment_path=["Stage[main]", "Main", "File[/tmp/foo]"], @file="", @line=1, @evaluation_time=nil, @change_count=0, @out_of_sync_count=1, @tags=#<Puppet::Util::TagSet: {"file", "class"}>, @time=2018-02-05 14:44:12 -0800, @out_of_sync=true, @changed=false, @skipped=false, @failed=true, @corrective_change=false, @events=[#<Puppet::Transaction::Event @name=":resource_error" @message=""resource is part of a dependency cycle"">]>}>
irb(main):005:0> a.exit_status
=> 4
irb(main):006:0>

John Duarte (JIRA)

unread,
Oct 21, 2019, 10:48:06 AM10/21/19
to puppe...@googlegroups.com
John Duarte updated an issue
 
Change By: John Duarte
QA Risk Assessment: Needs Assessment No Action
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages