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.
Best Answer
Yes, you can use that define outside the class it's created in, but you may need to include the class to ensure the define is parsed first, and the name of the individual resource is based on the class the define is in, not where the class is called.
Here's a complete working tested example (tested on CLI with puppet apply and correct nodename):
Output confirms that both happen: