Puppet users - May 2013 - How to apply to all hosts with exception list.

Hi all,

I know that there are likely a few ways to solve the following. I just
don''t know what the best way may be :)

We''re trying to work out how do something similar to the following
scenario.

How do we apply a policy to uninstall CUPS from all servers, except for  a
configurable group of "some".

To put it another way, how can we have an policy that will configure CUPS
on a known list of servers (hiera array perhaps?), and uninstall from all
other $kernel=Linux machines?

Best to get the install list right first then feed via ENC, or?

Regs,

Stephen

-- 
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+unsubscribe@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.

On 17 May 2013 10:33, Stephen Wallace <whizbang.wallace@gmail.com> wrote:
> Hi all,
>
> I know that there are likely a few ways to solve the following. I just
> don''t know what the best way may be :)
>
> We''re trying to work out how do something similar to the following
> scenario.
>
> How do we apply a policy to uninstall CUPS from all servers, except for  a
> configurable group of "some".
>
> To put it another way, how can we have an policy that will configure CUPS
> on a known list of servers (hiera array perhaps?), and uninstall from all
> other $kernel=Linux machines?
>
Since you haven''t actually mentioned how you are doing it I am going to
assume you have your cups package resource in a class or module somewhere
that gets included on all node.
Am I right?

If that is the case and you are running puppet 2.7+ or 3.x I would suggest
using a hiera variable and then use that variable to decide if it gets
uninstalled or setup.
Since the most likely case is to make sure it is uninstalled I would set
that as a default and override on the nodes you want it setup.

>
> Best to get the install list right first then feed via ENC, or?
>
> Regs,
>
> Stephen
>
> --
> 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+unsubscribe@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.
>
>
>
-- 
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+unsubscribe@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.

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.

On Thursday, May 16, 2013 6:33:25 PM UTC-6, Stephen Wallace
wrote:
>
> Hi all,
>
> I know that there are likely a few ways to solve the following. I just 
> don''t know what the best way may be :)
>
> We''re trying to work out how do something similar to the following
> scenario.
>
> How do we apply a policy to uninstall CUPS from all servers, except for  a 
> configurable group of "some".
>
> To put it another way, how can we have an policy that will configure CUPS 
> on a known list of servers (hiera array perhaps?), and uninstall from all 
> other $kernel=Linux machines?
>
> Best to get the install list right first then feed via ENC, or?
>
> Regs,
>
> Stephen
>  
-- 
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+unsubscribe@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.

On 17 May 2013 13:05, joe <lavaman@gmail.com> 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.

Using your solution you will still needs include that class individually on
the nodes that need cups installed.
How will you decide that?

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.


>
> On Thursday, May 16, 2013 6:33:25 PM UTC-6, Stephen Wallace wrote:
>>
>> Hi all,
>>
>> I know that there are likely a few ways to solve the following. I just
>> don''t know what the best way may be :)
>>
>> We''re trying to work out how do something similar to the
following
>> scenario.
>>
>> How do we apply a policy to uninstall CUPS from all servers, except for
>> a configurable group of "some".
>>
>> To put it another way, how can we have an policy that will configure
CUPS
>> on a known list of servers (hiera array perhaps?), and uninstall from
all
>> other $kernel=Linux machines?
>>
>> Best to get the install list right first then feed via ENC, or?
>>
>> Regs,
>>
>> Stephen
>>
>  --
> 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+unsubscribe@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.
>
>
>
-- 
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+unsubscribe@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.

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+unsubscribe@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.