On Thursday, May 16, 2013 10:34:26 PM UTC-5, Pete wrote:
>
> On 17 May 2013 13:05, joe <lav...@gmail.com <javascript:>> wrote:
>
>> The easiest thing to do would to make a subclass called cups::enabled or
>> similar and use an override:
>>
>> class cups::enabled inherits cups{ # The inherits is important
>>
>> Package['cups']{
>> ensure => 'present,
>> }
>>
>> Add service and config file resources here
>>
>> }
>>
>> The problem with trying to use hiera is it just gets you the package
>> ensure parameter. With the override, you can add in the service and config
>> file resources as well.
>
>
> Um what?
> Hiera is only for setting variables, usually for paremeterized classes.
>
I think that's a mischaracterization. Hiera is for dynamically loading
external data into Puppet. Often those data are used as the values of
variables -- including, but not limited to, class parameters -- but not
always. In any case, that misses the point: even if the data are stored
puppet-side in variables, it's all about what you do with them.
One thing you can do with hiera data is use it to choose which classes to
apply. That could be via conditional statements, but more interestingly,
it could also be by directly loading the names of the wanted classes from
hiera, and passing them directly to the 'include' function.
The most common other ultimate use of hiera data is to feed it to resources
as resource parameters (or parts of them) and/or to interpolate it into
templates. That's not disjoint from the other, however. For example, you
can use hiera data as a parameter of a resource of a defined type, which
might in turn use it in a conditional test to make decisions about which
classes to apply.
>
> Using your solution you will still needs include that class individually
> on the nodes that need cups installed.
> How will you decide that?
>
How will you do that via hiera? Hiera is a valuable tool, but it is not a
silver bullet. If you use hiera for the job then you still need to arrange
for the correct nodes to get the correct data. If the decision is based on
some grouping already modeled in Puppet, then it might actually fall out
easier to use that existing grouping directly, instead of pushing the data
out to hiera. Example:
node default {
include site::printing
include site::other_default_config
}
node /cups-[0-9]+/ inherits default {
include site::printing::enabled
}
>
> If you have one module included on each node and a class variable set with
> hiera to determine which nodes need cups and which don't you can use that
> in the class to uninstall cups or turn off the service or whatever you like.
>
> Hiera is about separating that data from your code and making it more
> portable.
> So in this case it is the best way to achieve that with minimal headaches
> and code rewrites in the future.
>
>
The subclassing approach is a bit old-school, but it's perfectly viable.
At one time it would have been the clear best choice for how to handle a
problem of this kind, and I'm not persuaded that using external data
instead is now always preferable. Indeed, a key question to answer is
where you want the distinguishing data to reside: in your manifests (not
necessarily in the form of a variable) or external.
If the question of whether CUPS should be installed or absent is a function
of nodes' roles, or something similar that has its own representation among
your manifests (e.g. a class applied only to nodes belonging to the given
group, or a node declaration by which group members are recognized and
characterized) then it is logical to encode the data into your manifests as
a characteristic of nodes having that role. If it's a node-by-node
decision, however, or if the group otherwise corresponds to a division at
some level of your hiera hierarchy, then it makes sense to put the data in
hiera.
In the end, though, there are still two general approaches to the problem:
1. apply some class to all nodes that chooses, on some basis, whether to
ensure CUPS uninstalled or installed and ready, or
2. apply a class to all nodes that ensures the default case (CUPS
uninstalled), and override it for those exceptional nodes that should
provide CUPS services.
Joe is right that option (1) would need more than just loading the value of
an 'ensure' parameter from hiera. If CUPS is supposed to be configured on
the node, then you need also to trigger the corresponding config file and
service resources, and possibly other resources as well. On the other
hand, that could still all be controlled by a single flag datum loaded via
hiera:
node default {
include site::printing
}
class site::printing($enabled = 'no') {
# parameter site::printing::enabled is expected to be loaded
# via hiera, at least when the value need to be 'yes'
if $enabled == 'yes' {
package { 'cups': ensure => 'latest' }
service { 'cups': ... }
...
} else {
package { 'cups': ensure => 'absent' }
}
}
All solutions I have imagined are variants of one of those, but I don't
have enough information to judge which might be more suitable for the OP's
specific case. I think I am safe to say, however, that neither is
inherently *un*suitable.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
