Puppet users - Nov 2006 - Reusable definitions

Hi there,

I would like to use puppet to configure two networks and one of the first
things I''ve tried to do is to describe ntp configuration. Each network
has a
ntp server that acts as a proxy for internal nodes, so those internal nodes
share the same configuration except for the server they use to get the time.


Attempting to describe this I''ve thought of several approaches, and
would
like to hear comments on them:

1. Use a component to describe an ntp_client. Kind of:

define ntp_client( $ntp_server ) {
  package { ntp ... }
  file { "/etc/ntp.conf" :
    content => template( "ntp.conf" ) ... <= Template using
<%= ntp_server
%>
  }
  service { ntpd ...
  }
}

node node1 {
  ntp_client { ntp_server => "server" }
  }
}


2. Use kind of a "parameterized" class. Kind of:

$ntp_server = $domain ? {
  "domain1.com" => "server.domain1.com ",
  "domain2.com" => "server.domain2.com",
  default => "es.pool.ntp.org"
}


class ntp_client {
  package { ntp ... }
  file { "/etc/ntp.conf" :
    content => template( "ntp.conf" ) ... <= Template using
<%= ntp_server
%>
  }
  service { ntpd ...
  }
}

node node1 {
  include ntp_client
  }
}


3. Maybe using inheritance? Kind of:

class abstract_ntp_client {
$ntp_server = "es.pool.ntp.org"
  package { ntp ... }
  file { "/etc/ntp.conf" :
    content => template( "ntp.conf" ) ... <= Template using
<%= ntp_server
%>
  }
  service { ntpd ...
  }
}

class ntp_client_domain1 inherits abstract_ntp_client {
$ntp_server = "server.domain1.com"
}

node node1 {
  include ntp_client_domain1
}


I guess my problem is that I would like to have some kind of reusable
definitions that I can "instantiate" providing some parameters, so I
can
describe classes and nodes using those definitions as building blocks (the
same as puppet types, I guess). From that point of view solution 1 seems the
right one, but as the documentation states, this could cause problems with
multiple components trying to manage the same instance.

If I approach this thinking about classes, it seems logical that two
computers that have some difference in their configuration should belong to
different classes, so from this point of view solution 3 seems to be
adequate, but then we have the scalability problem: if I want to manage a
large number of different networks the manifest would grow with something
that seems unnecessary.

Finally, solution 2 seems to provide decent scalability, as adding a new
network would mean adding a new line to the variable definition, and it fits
with the idea that, after all, all those machines are ntp_clients, although
they are using different ntp servers. In this case, as I told before, I have
the feeling of doing some ugly hack to achieve the goal of describing their
configuration with just a class which behavior is being modified using an
external variable.

Comments?

Thanks a lot in advance, best regards
Jose


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

José González Gómez wrote:
> 
> 1. Use a component to describe an ntp_client. Kind of:
[snip]

This will work, but it''s kind of an abuse because Puppet won''t
protect
you from calling that definition more than once, which would be a 
compile error.
> 2. Use kind of a "parameterized" class. Kind of:
> 
> $ntp_server = $domain ? {
>   " domain1.com <http://domain1.com>" =>
"server.domain1.com
> <http://server.domain1.com>",
>   "domain2.com <http://domain2.com>" => "
server.domain2.com
> <http://server.domain2.com>",
>   default => "es.pool.ntp.org <http://es.pool.ntp.org>"
> }
> 
> 
> class ntp_client {
>   package { ntp ... }
>   file { "/etc/ntp.conf" :
>     content => template( "ntp.conf" ) ... <= Template using
<%=
> ntp_server %>
>   }
>   service { ntpd ...
>   }
> }
> 
> node node1 {
>   include ntp_client
>   }
> }
I consider this to be the best solution, although I agree that it''s not
exactly elegant.  Puppet classes *definitely* need to support parameters 
in some way, I just haven''t had time to add them.
> 3. Maybe using inheritance? Kind of:
> 
> class abstract_ntp_client {
> $ntp_server = "es.pool.ntp.org <http://es.pool.ntp.org>"
>   package { ntp ... }
>   file { "/etc/ntp.conf" :
>     content => template( "ntp.conf" ) ... <= Template using
<%=
> ntp_server %>
>   }
>   service { ntpd ...
>   }
> }
> 
> class ntp_client_domain1 inherits abstract_ntp_client {
> $ntp_server = "server.domain1.com
<http://server.domain1.com>"
> }
This won''t work.  The parent class won''t look up variables in
the child
class.  I can''t really decide if this is a bug or not; it''s
pretty clear
  that many people expect this to work, but I''m not sure it''s
possible.
> I guess my problem is that I would like to have some kind of reusable 
> definitions that I can "instantiate" providing some parameters,
so I can
> describe classes and nodes using those definitions as building blocks 
> (the same as puppet types, I guess). From that point of view solution 1 
> seems the right one, but as the documentation states, this could cause 
> problems with multiple components trying to manage the same instance.
As I said, parameterized classes are the best solution, but they don''t 
exist at this point.

-- 
Morgan''s Second Law:
    To a first approximation all appointments are canceled.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com