Puppet users - Dec 2012 - How to only apply my manifests to certain classes?

Hi,

I''ve written a new resolv class, but I only want it to get pushed out
(for
instance) UAT servers for now. Or perhaps just servers which have apache 
installed, or just the ones which are part of project xyz.

I''ve been searching through the docs, but I think I''m looking
in the wrong
place. Also, I get the feeling that there''s several ways to achieve
this
and some of the docs refer to the older ways.

What''s the current method of limiting certain manifests to certain
classes
of machines? (have I got my terminology wrong here?) 

Perhaps someone could put a link in to the best place in the docs that 
explains this to me? I''m sure I''ve read about this in the
past, but I can''t
seem to find it again.

Thanks in advance! 

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/eLOq3hnPSroJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Dec 20, 2012 at 4:11 PM, Steve Button <steve.button@gmail.com>
wrote:
> Hi,
>
> I''ve written a new resolv class, but I only want it to get pushed
out (for
> instance) UAT servers for now. Or perhaps just servers which have apache
> installed, or just the ones which are part of project xyz.
Depending on the size and complexity of your environment, there''s
several ways of achieving those goals.
> I''ve been searching through the docs, but I think I''m
looking in the wrong
> place. Also, I get the feeling that there''s several ways to
achieve this and
> some of the docs refer to the older ways.
Yes, there are several ways, and I think the docs cover all of them,
at least to a certain degree.
> What''s the current method of limiting certain manifests to certain
classes
> of machines? (have I got my terminology wrong here?)
Using the word ''classes'', whilst not incorrect, may cause
confusion,
as a class is something special in puppet terminology.
> Perhaps someone could put a link in to the best place in the docs that
> explains this to me? I''m sure I''ve read about this in the
past, but I can''t
> seem to find it again.
OK.  If you''re trying to apply your resolv class based on the fact
that Apache is installed, I''d recommend resource dependencies (docs at
http://docs.puppetlabs.com/learning/ordering.html):

apache { ''vhost-title'':
  parameter => value,
  param2 => value,
  before => resolv[''resolv.conf'']
}

I personally don''t like having dependencies ordered that way (I prefer
''require''), but given your use case of ''I know which
servers I want
Apache on, and resolv needs to be put on those same servers'' this
seems to be the more natural way of writing your manifest.

The most flexible way of assigning classes to nodes is via an External
Node Classifier, or ENC.  Documentation at
http://docs.puppetlabs.com/guides/external_nodes.html.  I think this
is generally considered the ''correct'' method, given that
manually
updating site.pp is just unworkable in any large(ish) setup.

For your ''I want to assign the class to all servers in XYZ
project'',
the first question you have to answer is ''how do you define which
servers are in project ''xyz''.  If it''s hostname
based, your ENC has
direct access to that (the ENC script is called with the hostname as a
parameter).  If it''s some other property of the server, it may already
be available as a facter variable, which are easily obtainable via
calling out to the ''facter'' binary in your script.  If
it''s some other
property, you''ll have to somehow make that available to your ENC
script.  That could be done via a custom fact, which is documented at
http://docs.puppetlabs.com/guides/custom_facts.html.

Regards,

Matt.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Dec 20, 2012 at 8:11 AM, Steve Button <steve.button@gmail.com>
wrote:
> Hi,
>
> I''ve written a new resolv class, but I only want it to get pushed
out (for
> instance) UAT servers for now. Or perhaps just servers which have apache
> installed, or just the ones which are part of project xyz.
There are a couple of ways how you can achieve that depending
on your existing setup of Puppet:
   * via ENC (external node classifier)
      http://docs.puppetlabs.com/guides/external_nodes.html
   * node definition
      http://docs.puppetlabs.com/puppet/2.7/reference/lang_node_definitions.html
   * good ol'' case statements in your site.pp
      case $::fqdn {
          ....
      }
   * manual execution of puppet apply with that single class given to it
      echo ''your_class'' | puppet apply

Please let us know a bit more about your setup.

Thanks,
Roman.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

An option that hasn''t been mentioned yet is hiera. It''s great
to use for
data, but you can also use it to say what classes get applied to what 
nodes. You define some variable in your hierarchy, say
''classes'', which is
an array of class names to be included, and then in your default node 
definition, you use hiera_include(''classes''), which will get
the names from
all ''classes'' variable in the hierarchy that matches the node
checking in
and include them.

On Thursday, December 20, 2012 8:11:42 AM UTC-8, Steve Button
wrote:
>
> Hi,
>
> I''ve written a new resolv class, but I only want it to get pushed
out (for
> instance) UAT servers for now. Or perhaps just servers which have apache 
> installed, or just the ones which are part of project xyz.
>
> I''ve been searching through the docs, but I think I''m
looking in the wrong
> place. Also, I get the feeling that there''s several ways to
achieve this
> and some of the docs refer to the older ways.
>
> What''s the current method of limiting certain manifests to certain
classes
> of machines? (have I got my terminology wrong here?) 
>
> Perhaps someone could put a link in to the best place in the docs that 
> explains this to me? I''m sure I''ve read about this in the
past, but I can''t
> seem to find it again.
>
> Thanks in advance! 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/M6v-9rMzbj0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday, December 20, 2012 10:51:40 AM UTC-6, Matthew Burgess
wrote:
>
> On Thu, Dec 20, 2012 at 4:11 PM, Steve Button
<steve....@gmail.com<javascript:>>
> wrote: 
>
> OK.  If you''re trying to apply your resolv class based on the fact
> that Apache is installed, I''d recommend resource dependencies
(docs at
> http://docs.puppetlabs.com/learning/ordering.html): 
>
> apache { ''vhost-title'': 
>   parameter => value, 
>   param2 => value, 
>   before => resolv[''resolv.conf''] 
> } 
>
>
Unfortunately, that doesn''t address the question.  The
''before'' and
''require'' metaparameters direct the ordering of resources that
have been
declared, but they do not themselves declare resources.  The resources they 
reference must be declared separately (and those declarations must have 
already been parsed).

This answer does lead toward a general Puppet truth however: it is 
preferable to tell Puppet how things *should be* instead of asking it to 
adapt to how things *are*.  Thus, if Apache servers should all have your 
''resolv'' class then your manifests should ensure that nodes
you are
configuring with Apache also get resolv.

 
> I personally don''t like having dependencies ordered that way (I
prefer
> ''require''), but given your use case of ''I know
which servers I want
> Apache on, and resolv needs to be put on those same servers'' this 
> seems to be the more natural way of writing your manifest. 
>

Except that the declaration doesn''t say that.  In fact, a relationship
is
probably not warranted here at all, because it doesn''t matter
(probably) in
which order the resources are applied to target nodes -- it only matters 
that nodes that get Apache also get resolv.

 
>
> The most flexible way of assigning classes to nodes is via an External 
> Node Classifier, or ENC.  Documentation at 
> http://docs.puppetlabs.com/guides/external_nodes.html.  I think this 
> is generally considered the ''correct'' method, given that
manually
> updating site.pp is just unworkable in any large(ish) setup.
>

I think that''s overstating it a bit.  An ENC is certainly a viable 
solution, and a lot of people use them, but in some ways they can be a lot 
more tedious and error prone than well-written manifests.  Even if your 
site uses an ENC, when you have firm configuration rules that can be 
expressed in Puppet DSL then it is better to express them that way.

For example, supposing that class ''resolv'' is not parametrized
or does not
need to be declared with custom parameters (one of which should be your 
goal), and supposing that you have a class ''apache'' with which
you
configure your apache nodes, all you need to do to ensure that all apache 
servers have class ''resolv'' is put

    include ''resolv''

at the top of class apache''s body.  Done.
 
>
> For your ''I want to assign the class to all servers in XYZ
project'',
> the first question you have to answer is ''how do you define which 
> servers are in project ''xyz''.  If it''s hostname
based, your ENC has
> direct access to that (the ENC script is called with the hostname as a 
> parameter).  If it''s some other property of the server, it may
already
> be available as a facter variable, which are easily obtainable via 
> calling out to the ''facter'' binary in your script.  If
it''s some other
> property, you''ll have to somehow make that available to your ENC 
> script.  That could be done via a custom fact, which is documented at 
> http://docs.puppetlabs.com/guides/custom_facts.html. 
>
>
All true, but none of it elects an ENC as the best consumer of the data.  
I''d rate hiera as a particularly good approach for a case such as this
one.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/vfhKSbUoSSMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday, 20 December 2012 16:51:59 UTC, rvs wrote:
> On Thu, Dec 20, 2012 at 8:11 AM, Steve Button
<steve....@gmail.com<javascript:>>
> wrote: 
> > Hi, 
> > 
> > I''ve written a new resolv class, but I only want it to get
pushed out
> (for 
>
>
> Please let us know a bit more about your setup. 
>
> Thanks, 
> Roman. 
>
I''ve used puppet before at several companies, but it''s always
been already
set up before I arrived and I''ve only modified the existing manifests. 

Currently I''m at a new site and we''re not using Puppet at all,
just at the
proof of concept stage. 

I''m aware Puppet is very powerful, which also means it could be very 
dangerous. I''d like to avoid bringing down the whole IT infrastructure
(of
course) by rolling out a change to resolv.conf, for example, which could 
potentially cripple a node. When I make a change I''d like to first test
it
on one single node, then perhaps 10 in Dev, then after a day or so the rest 
of Dev. Likewise for UAT and Prod environments. So, that''s one 
requirement... to be able to roll things out gradually to give it time to 
spot mistakes in the code. 

I guess the apache / resolv example is a little contrived, and doesn''t 
represent a real use case. More likely we might want certain packages / 
kernel setting on our Oracle servers, but different ones on our SAP 
servers. Looking at the example pointed to...

node ''www1.example.com'', ''www2.example.com'',
''www3.example.com'' { include
common include apache, squid }

I guess I could add "include uat" and then put things that are
specific to
UAT servers only in there. 

Thanks for all the pointers, I think I''ve got a lot of reading to do
and
feeling a little overwhelmed!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/w57-Fbff3e4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

This is an excellent post on how to organize those types of dependencies.

http://www.craigdunn.org/2012/05/239/

On Friday, December 21, 2012 4:10:45 AM UTC-7, Steve Button
wrote:
>
> On Thursday, 20 December 2012 16:51:59 UTC, rvs wrote:
>
>> On Thu, Dec 20, 2012 at 8:11 AM, Steve Button
<steve....@gmail.com>
>> wrote: 
>> > Hi, 
>> > 
>> > I''ve written a new resolv class, but I only want it to
get pushed out
>> (for 
>>
>>
>> Please let us know a bit more about your setup. 
>>
>> Thanks, 
>> Roman. 
>>
>
> I''ve used puppet before at several companies, but it''s
always been already
> set up before I arrived and I''ve only modified the existing
manifests.
>
> Currently I''m at a new site and we''re not using Puppet at
all, just at the
> proof of concept stage. 
>
> I''m aware Puppet is very powerful, which also means it could be
very
> dangerous. I''d like to avoid bringing down the whole IT
infrastructure (of
> course) by rolling out a change to resolv.conf, for example, which could 
> potentially cripple a node. When I make a change I''d like to first
test it
> on one single node, then perhaps 10 in Dev, then after a day or so the rest
> of Dev. Likewise for UAT and Prod environments. So, that''s one 
> requirement... to be able to roll things out gradually to give it time to 
> spot mistakes in the code. 
>
> I guess the apache / resolv example is a little contrived, and
doesn''t
> represent a real use case. More likely we might want certain packages / 
> kernel setting on our Oracle servers, but different ones on our SAP 
> servers. Looking at the example pointed to...
>
> node ''www1.example.com'',
''www2.example.com'', ''www3.example.com'' {
include
> common include apache, squid }
>
> I guess I could add "include uat" and then put things that are
specific to
> UAT servers only in there. 
>
> Thanks for all the pointers, I think I''ve got a lot of reading to
do and
> feeling a little overwhelmed!
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/QwjnSscd8KYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.