Puppet – Don’t stop manifest execution if a module fails

puppet

I'm having some trouble understanding one of many Puppet logic mechanisms : the module failing scenario.

I have multiple modules doing various things on a set of differences nodes and I want to implement the following scenario :

deploy all modules for specified nodes
if a module execution fails, only fail this module but keep applying other modules

I wrote something along these lines in my test module (yum) :

init.pp :

class yum {
    case $operatingsystem { 
        /(RedHat|CentOS)/ : { include yum:config }
        default:            { include yum:fail }
    }
}

class yum::config {
    debug("[${fqdn}] Deploying yum.conf file")
    #DEPLOY YUM.CONF CODE
}

class yum:fail {
    fail("[${fqdn}] This module is only for RedHat or CentOS")
}

And in my site.pp manifest :

node 'redhat', 'centos', 'debian' {
    include yum
    include motd
}

The problem is, if the operatingsystem case is not satisfied by a given node (debian in this instance), it will fail all consecutive modules (motd will NOT be applied).

So the question is : what am I doing wrong in this case ?

PS: Keep in mind that I'm still in the process of learning Puppet best practices and, as such, I am not pretending my code is spotless.

Best Answer

Silly me. It seems indeed that, considering my module structure, I just have to do nothing once we are in the child class yum::fail (maybe just put an info and/or debug message). No need to fail it explicitly.

Related Solutions

Referencing groups/classes from Puppet dashboard in the site manifest

You are on the right track with the External Node Classifier. It is a bit difficult to wrap your head around, but one you get it working you will never look back and I cannot recommend doing it strongly enough. I went to the puppet IRC room when i had trouble and they helped me get mine working.

Applying different modules based on OS is fine. I run a 300+ node environment with BSD and RHEL and we do it. Instead of having the the OS be a node, we have it as own class because . So instead of "node OS inherits basenode", we do have the ENC pass back something like this:
```
node web-prod-007 {
  $node_environment="production"
  include web_server_class # this then inherits basenode
  include centos6::server # 
  include logging::rsyslog 
}
```
...etc

how you do it depends on how you want your inheritance to work, if you want to modify the things in basenode depending on operating system, then having OS inherit basenode is the right way to go.

TLDR, what you are doing is okay, and look into ENC's because they make life easier.

EDIT: 2. I dont use Dashboard so I dont know.

How to redefine parameters in subclass

Answer the meta question of how do you make this work, If you're using Passenger to run your Puppet master, which you should if you've a system of any size, there is a simple workaround to the madness that is the puppetlabs module. You simply drop a new file called /etc/puppet/puppetmaster.conf and maybe some other bits of config in a new module called puppetmaster and also add this line to the config.ru

ARGV << "--config=/etc/puppet/puppetmaster.conf"

You can use some of the logic inside the puppetlabs module, but it might be simpler to just push a file or less complex template if you don't care about having every single bit of config as a parameter. Then include puppetmaster on the nodes that are masters and you're set. You can also modify the existing puppetlabs to do the above.

Addressing the original question, Hiera might be the simplest solution. Use this in the init.pp

$master                   = hiera('puppet_master','false'),

and then set puppet_master: true for the machines that need it. Personally my preference is for the first method.

Related Topic