Issue #21326 has been updated by Charlie Sharpsteen. Status changed from Unreviewed to Needs Decision Assignee set to eric sorenson
Eric, any thoughts on this? This ticket is requesting something similar to `noop => true` with the difference being that any resource requiring or subscribing to the no-oped resource will fail if there are changes pending. ---------------------------------------- Feature #21326: Add parameter to fail puppet run if resource does not match definition https://projects.puppetlabs.com/issues/21326#change-94191 * Author: Nick Walker * Status: Needs Decision * Priority: Normal * Assignee: eric sorenson * Category: * Target version: * Affected Puppet version: * Keywords: customer * Branch: ---------------------------------------- A customer wrote in with the following: I've been writing a lot of puppet manifests and I've found myself wanting the following feature several times: Allow the ability for a resource to fail if the current system state doesn't match the resource definition instead of trying to correct it by installing a package or creating a file. This would be useful for situations where a manual step must be performed and we just want to use puppet to verify that it has been done prior to applying the rest of the manifests. Ideally each resource would have a parameter called something like 'otherwise' which would default to 'correct', i.e. 'perform whatever action is necessary to bring the system into compliance with the definiton'. But if set to something like 'fail', then no action would be performed and the run would just fail. For example, we use a system called Centrify Direct Connect to manage unix users with Active Directory. The installation of Centrify is a manual process, but one that results in the packages 'centrifyd c', and 'centrifydc-openssh' being installed (on both redhat and debian systems). We'd like to be able to do the following: package { ['centrifydc', 'centrifydc-openssh']: ensure => 'installed', otherwise => 'fail', } We also run a hadoop cluster, and the namenode service shouldn't run unless HDFS has been formatted with hdfs namenode -format. However, since a format is a potentially destructive operation, we don't want puppet automatically running that command under any circumstances. We want that to be a manual step. There is a way to verify that it has been done by checking for the existence of a file, but we wouldn't want puppet creating it if it doesn't exist, just fail. So the following would be nice: file { 'formatted-hdfs': path => '/data/nn/current/fsimage', ensure => 'file', otherwise => 'fail', } And then the services could just require File['formatted-hdfs'] without fear that an empty fsimage file would be created by puppet (which could possibly corrupt the entire HDFS). Obviously a lot of this can be worked around with exec commands that return a non-zero status code when things aren't as one wants. But then we'd need to rewrite a lot of what puppet already does. For example, with Centrify, we'd have to check if the system is debian or redhat and then run either dpkg or yum to check for the existence of a package, something package already does. -- 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.
