Issue #20679 has been updated by Sean Millichamp.
Eric, To your point, in the specific case I cited I would agree that yes, it is perhaps particular to my environment. It was explicitly intended to leverage the features and capabilities of the language (intentional or not) to ensure a noop run has the expressiveness needed to produce useful feedback to the end-user. That said, I think it is very valid to let the developer have the expressiveness in their own modules to choose to either allow the command line/config file specified behavior OR, because they know the use case of their module, choose to selectively override it. If you want the default behavior of "noop means noop" then the answer seems simple: don't override it at the resources. To me this smacks of the old "Doctor, it hurts when I do this" joke to which the doctor replies "so don't do it". Overriding the behavior at noop at the resource level is a intentional, specific design choice when writing modules. If you want your resources to behave per defaults, you have the option of either not specifying noop at all or specifying noop and passing "undef" to it. To the original poster of this issue: One possible solution to consider isn't to ban the use of noop in manifests, but instead to set site-standards around how and where to use noop. This is what we have done. In fact, EVERY resource is required/expected to have noop specified via a parameter and, in 99% of cases, we pass down undef to preserve the command-line/config file specified behavior, but we have per-module level overrides available if needed exposed for most things as well as a handful of forced-state items such as concat (forced to either true or false as needed) This allows us a tremendous level of flexibility including situations such as: Setting a system to default in noop=true mode via the config file but ensuring the resources in one particular module are always applied (e.g.: to ensure some specific critical security policy is always enforced) Or, allowing a non-Puppet-savvy Linux admin to have this workflow: * Clone a copy of the prod environment into a dynamic test environment * Make a simple data-level change (e.g.: a new sudoers rule) in a cloned copy of the current Hiera tree * Go to whatever production host (or a representative host in a group) this change is intended to impact and do a "puppet agent --noop --env=my_temp_env" * have Puppet "do the right thing", which in this case means: Generating and deploying the rule into the concatfile system, building up a new sudoers in a staging area, AND running "visudo -c -f" on the staged sudoers file * The admin can now review not only a diff of the changes in the staged sudoers file versus the live sudoers file but also know that the file passed syntax validation BEFORE proceeding * Commit the change into the production Hiera, destroy the temporary environment, and wait for Puppet to roll it out. Note: They can run "puppet --noop" with the knowledge this operation is safe and not going to impact any system configuration items because of module design, code review, and testing, not because of any technical restriction. If --noop had forced all resource to be noop=true then all they would have gotten as feedback would have been a notice such as "File[/var/opt/lib/pe-puppet/clientdata/modules/concat/sudo/500-some-partial-fragment.part]: ensure created" which would have been not useful to them at all. To Kevin's suggestion, if you intend to do anything at all, I would strongly suggest perhaps adding a "dry-run" option that explicitly overrides all noop's to be true and leaving the noop behavior as is. Thanks. ---------------------------------------- Bug #20679: puppet agent --noop command line option does not guarantee a fully dry run https://projects.puppetlabs.com/issues/20679#change-93020 * Author: Nick Moriarty * Status: Needs Decision * Priority: High * Assignee: eric sorenson * Category: agent * Target version: * Affected Puppet version: 2.7.11 * Keywords: noop simulation dry-run dryrun simulate test backlog * Branch: ---------------------------------------- According to some documentation (including man pages), and common sense, specifying --noop should cause Puppet agent to run in 'dry-run' mode, and make no changes. However, it seems that this actually just changes the global resource default for 'noop' to true. If a resource is defined which determines noop itself (for example, based on a parameter), this will escape what would reasonably be expected to be a simulation run, as it will override the global noop with 'false'. I noticed this while testing a development branch and noting that it actually affected a file mode somewhere. If not implemented via the 'noop' mechanism, a proper simulation mode should be provided which will show exactly what will happen, but with the guarantee that nothing will be done. The current --noop flag certainly doesn't provide that guarantee. This issue may cause us to internally ban the use of 'noop' in manifests, as it leaves us with no way of guaranteeing a proper dry run. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
