Jira (PUP-1079) Exported resources is exporting to the database with --noop flag

[Rob Nelson (JIRA)]

Rob Nelson commented on PUP-1079

Re: Exported resources is exporting to the database with --noop flag Verified with Jason that this is now a critical issue, --noop is now unusable. This appears to need some engineering decisions on how to go forward or to leave as is. Add Comment

This message was sent by Atlassian JIRA (v6.3.7#6337-sha1:2ed701e)

[Deepak Giridharagopal (JIRA)]

Deepak Giridharagopal commented on PUP-1079

Re: Exported resources is exporting to the database with --noop flag

This is something we should look at sooner rather than later, though the obvious conundrum is that people are pretty attached to both behaviors Christophe identified. For the folks that want noop to no longer export resources, a few questions: should facts get exported during a noop run? should this affect all resources marked as noop (say with the noop metaparameter)? if we had, say, an option in the puppetdb terminus config to prevent noop stuff from getting submitted, would that suffice? Pinging Ryan Senior, Kenneth Barber, and Wyatt Alt for awareness.

Add Comment

This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a)

[Jason Antman (JIRA)]

Jason Antman commented on PUP-1079

Re: Exported resources is exporting to the database with --noop flag

Deepak Giridharagopal Yeah, that is a bit of a dilemma. Speaking for myself: Whether or not facts get exported isn't a big deal to me, as that shouldn't affect my actual catalogs. People who are using something like puppetdbquery might feel otherwise, and want to prevent fact updates as well. I can see arguments in favor of 'yes' or 'no' about this, but don't have a strong opinion for my use case. Resources marked as noop... I'm honestly not sure. I'm leaning towards no (it shouldn't affect them) on the assumption that if a resource is exported with noop => true, it will end up (correctly) being a noop on the collecting node, but I haven't tested this. Yes. I understand that this would be a change to current behavior, and I'd be perfectly happy with making that a configuration option, so those of us who want the behavior to change have to explicitly specify it, so long as it's mentioned clearly in the Exported Resouces docs (one of my big gripes with this ticket is that as far as I know, there's nothing clear in the docs to explain that --noop runs still export resources).

Add Comment

[Rob Nelson (JIRA)]

Rob Nelson commented on PUP-1079

Re: Exported resources is exporting to the database with --noop flag

Deepak Giridharagopal For me, I'd say that noop, by definition, should not be expected to effect actual changes, so both facts and resources should not be exported. Since the master or agent in a masterless setup are what send the data to puppetdb, I feel any change in behavior should be made there, including config options. Otherwise, data could be sent over the wire that shouldn't be, even if puppetdb discards it. Even with encryption that's still putting some data at risk and increasing the network load. As mentioned, the docs don't explain this behavior and I would be surprised if new users expected this behavior, so it may be beneficial to set any new option to default to off in the next major release.

Add Comment

[John Duarte (JIRA)]

John Duarte updated an issue

Puppet / PUP-1079

Exported resources is exporting to the database with --noop flag

Change By: John Duarte Labels: customer  needs_decision  redmine

Add Comment

This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)

[John Duarte (JIRA)]

John Duarte updated an issue

Puppet / PUP-1079 Exported resources is exporting to the database with --noop flag

Change By: John Duarte Labels: customer needs_decision redmine  triaged

Add Comment

[Henrik Lindberg (JIRA)]

Henrik Lindberg updated an issue

Puppet / PUP-1079 Exported resources is exporting to the database with --noop flag

Change By: Henrik Lindberg When I run puppet with the noop flag resources are being exported to the db. I would expect it to simulate the transaction with the db... This is causing things like nagios host resources being  creating  created  before the plugins get there, so I get invalid alerts. -Andrew

Add Comment

[Henrik Lindberg (JIRA)]

Henrik Lindberg commented on PUP-1079

Re: Exported resources is exporting to the database with --noop flag This seems to have been critical and urgent in 2014 - what happened since then? Does this work as expected now (export of noop-resources)? Ping Russell Mull, Josh Cooper

Add Comment

[Rob Nelson (JIRA)]

Rob Nelson commented on PUP-1079

Re: Exported resources is exporting to the database with --noop flag

I still observe the behavior that noop runs actually export resources which may not be realized. As an example, if I run with --noop on the first run of an agent, it exports the ssh key, and then all the other nodes in my system start to collect the ssh key. That's not destructive like monitoring resources can be, but it's still not desired behavior.

Add Comment

[Russell Mull (JIRA)]

Russell Mull commented on PUP-1079

Re: Exported resources is exporting to the database with --noop flag

The obvious fix is to just not put the catalog from a --noop run into puppetdb. While I think that would be easy enough to implement, I'm worried that someone's workflow depends on this. Maybe we could just not send --noop catalogs by default but have an option to send them?

Add Comment

[Moses Mendoza (JIRA)]

Moses Mendoza updated an issue

Puppet / PUP-1079

Exported resources is exporting to the database with --noop flag

Change By: Moses Mendoza

Labels: customer needs_decision redmine  triaged

Add Comment

[Dimitri Tischenko (JIRA)]

Dimitri Tischenko commented on PUP-1079

Re: Exported resources is exporting to the database with --noop flag (Comment triggered by DOCUMENT-832) FWIW, I have a customer who is happy with the --noop mode preventing exported resources from expiration. From their perspective, if the agent does something useful on the node and a report gets sent, it's OK for exported resources to be updated.

Add Comment

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)

[Charmaine Pritchett (Jira)]

Charmaine Pritchett updated an issue

Puppet / PUP-1079

Exported resources is exporting to the database with --noop flag

Change By: Charmaine Pritchett Zendesk Ticket Count: 1 Zendesk Ticket IDs: 50720

Add Comment

This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)

[Charmaine Pritchett (Jira)]

Charmaine Pritchett updated an issue

Puppet / PUP-1079 Exported resources is exporting to the database with --noop flag

Change By: Charmaine Pritchett Labels: customer jira_escalated needs_decision redmine

Add Comment

[Xiuqing Jiang (Jira)]

Xiuqing Jiang commented on PUP-1079

Re: Exported resources is exporting to the database with --noop flag There is a APAC customer hit by this bug as well. Can we revisit this and to have this bug corrected? Thanks

Add Comment

[Xiuqing Jiang (Jira)]

Xiuqing Jiang updated an issue

Puppet / PUP-1079

Exported resources is exporting to the database with --noop flag

Change By: Xiuqing Jiang Labels: customer jira_escalated needs_decision puppet_agent redmine

Add Comment

[Xiuqing Jiang (Jira)]

Xiuqing Jiang updated an issue

Puppet / PUP-1079 Exported resources is exporting to the database with --noop flag

Change By: Xiuqing Jiang Affects Version/s: PUP 6.28.0

Add Comment

[Xiuqing Jiang (Jira)]

Xiuqing Jiang updated an issue

Puppet / PUP-1079 Exported resources is exporting to the database with --noop flag

Change By: Xiuqing Jiang Team: Phoenix

Add Comment

[Sean Millichamp (Jira)]

Sean Millichamp commented on PUP-1079

Re: Exported resources is exporting to the database with --noop flag I just noticed this issue and wanted to chime in and say I can see value in either behavior.  In general, I would prefer -noop runs to not affect the active catalog in PuppetDB for a given node as that is a surprising effect for most users. However, I also frequently use the current behavior of updating the catalog so I can use puppet query to dig through the catalog in PuppetDB to validate that the catalog looks how I would expect (especially in terms of exported resource generation). I suppose I could, as an alternate approach, look at the client's on-disk copy of the catalog on a -noop run instead but the client's copy is typically harder for me to access than the PuppetDB one.

Add Comment