How to override puppet class arguments in child node

Whenever you find yourself saying "I want this component to behave one way in one node, but a different way in another node", you probably need to be looking at a definition driven by variables, either via conditionals in the class definition, or substitutions in a template.

Unfortunately, your example shows you attempting to use inheritance, which is pretty badly broken in puppet and will cause you a lot of grief here because one of the things that it breaks is variable redefinition in nodes.

UPDATE: old answer details are obsolete

What I'm doing as of 2.7 is to ensure that all variables used by a class are not global variables at all, but rather parameters with reasonable defaults set. You still don't want to use the inheritance built into Puppet, but you can now override particular variables directly from the node definition, and you can even have a primitive form of inheritance manually by having one class take variables and then pass them to an invocation of another class. For example, you would have in your node definitions:

node experimental_server {
  # This will still call class 'databases', but will install Postgresql and not Mysql
  # as a default.  You can still override it the same way as with 'databases'
  class { 'mydept::nextgeneration': },
}
node server_with_mysql {
  class { 'databases':
    mysql_enabled => true,
  }
}
node server_with_no_db {
  class { 'databases': # this installs only the clients }
}

class databases (
  # By default, install no servers, just clients
  $pgsql_enabled => false,
  $mysql_enabled => false
)
{
  ...
}

class mydept::nextgeneration (
  # If not explicitly overridden, an undef value passed as a parameter to a class
  # assumes the default value in that class
  $mysql_enabled => undef,
  $pgsql_enabled => true
)
{
  class { 'databases':
    mysql_enabled => $mysql_enabled,
    pgsql_enabled => $pgsql_enabled,
  }
}

As a commenter noted, there is now also a nifty new feature called Hiera, which allows you to offload defaults into a separate data structure, and you should look into it if you have Puppet 3.2 available. Unfortunately, many Linux distributions are still shipping with 2.6 or 2.7, so this may not yet be an option for you.

Previous answer details preserved below

The way that I generally handle something like this is to create a 'default_parameters.pp' file that has nothing in it but default assignments for a long list of variables, so in this case, it would contain a line something like $mysql_enabled = false. This file is then included by the module's init.pp file. Then, the node definitions file would look something like:

import "mymodule"

node myserver.local {   # NOTE: no inheritance!
  $mysql_enabled = true
  include mysql::server
}

node otherserver.local {
  include mysql::server
}

Then in the class definition for mysql::server you check if $mysql_enabled is true, and if so, use a selector on enable and ensure.

This breaks instantly if node myserver.local inherits anything, because that will lock the value of the variables at inherit time, and further changes inside the node definition will have no effect, but otherwise I use this technique all over the place to have individual components behave differently without generating multiple classes.

If you absolutely have to have inheritance, but the list of machines with mysql enabled is small, you can take an alternate route: instead of setting a variable in the node definition, build your selector off of $fqdn, with the default to disable, and selected fqdns enabled.

Resources in Puppet have to be unique, i. e. have to have a unique name.

In the described case, you had the resource Exec["sleep 5"] in your definition and every time you call srv (it's basically the same as including a parameterized class), the resource Exec["sleep 5"] will also be included and thus the parser finds two or more resources with the same name.

By appending the $name of the definition to the name of your Exec resource, you make it unique. Well, at least most likely unique since when you have another resource with the same name (Exec["sleep 5 for foo") somewhere else in your manifests, you'll run into this error again.