Puppet users - Nov 2011 - parameterized module and flow control

Hi guys,

For a project I''m working on for my studies we need to create a demo
setup
of a small enterprise environment. The linux-part of this is now managed by 
puppet. However, I''m running into something I can''t exactly
figure to how
to fix. I''ve read the docs a few times but I can''t find a
clear indication
on how to solve this and what would be the recommended way, Google left me 
out in the cold too.

What I basically need is flow control for my installation. In the current 
state I want to create an nginx-module that handles a few things. My main 
issue is that I want this parameterized. Depending on a parameter fed to 
that module I want to change the packages installed and additional classes 
being called upon.

I''d like to be able to do something like this:
nginx(type=default), install nginx, call nginx::conf
nginx(type=ruby), install nginx-extras, call nginx::conf, call 
nginx::conf::passenger
nginx(type=php), install nginx, php5-fpm, call nginx::conf, call 
nginx::conf::php

And so forth. I''d rather not split this up into different modules, imho
that''s ugly but I can''t figure out how to do it this way in
puppet either.
Can anyone point me in the right direction?

Kind regards,

-- 
Daenney

-- 
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/-/7sMpz4YucOEJ.
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 Nov 1, 3:30 am, Daenney <daniele.sluijt...@gmail.com>
wrote:
> Hi guys,
>
> For a project I''m working on for my studies we need to create a
demo setup
> of a small enterprise environment. The linux-part of this is now managed by
> puppet. However, I''m running into something I can''t
exactly figure to how
> to fix. I''ve read the docs a few times but I can''t find a
clear indication
> on how to solve this and what would be the recommended way, Google left me
> out in the cold too.
>
> What I basically need is flow control for my installation. In the current
> state I want to create an nginx-module that handles a few things. My main
> issue is that I want this parameterized.

And that''s your first mistake.  Functionally, class parameterization
gains you nothing that you cannot achieve in other ways, but it costs
you flexibility.

As you are a student, I suppose you have some programming background.
That''s ok, you can probably learn Puppet anyway.

Seriously, there is a mental adjustment to make when shifting from a
procedural programming language to a declarative language such as
Puppet DSL.  To use Puppet effectively you need to get over that
hump.  Among other things, wipe the word "call" and its synonyms out
of your Puppet vocabulary.  They will only lead you astray.

> Depending on a parameter fed to
> that module I want to change the packages installed and additional classes
> being called upon.
>
> I''d like to be able to do something like this:
> nginx(type=default), install nginx, call nginx::conf
> nginx(type=ruby), install nginx-extras, call nginx::conf, call
> nginx::conf::passenger
> nginx(type=php), install nginx, php5-fpm, call nginx::conf, call
> nginx::conf::php
>
> And so forth. I''d rather not split this up into different modules,
imho
> that''s ugly but I can''t figure out how to do it this way
in puppet either.

I find "include ''nginx::php''" a lot more readable
than "class
{ ''nginx'': type => ''php'' }", myself,
but whatever.  Your essential
problem is not related to parameterization.

> Can anyone point me in the right direction?

1) You do not need flow control, which is good because Puppet does not
offer it.  You do need to define proper relationships among your
resources and/or classes, however, to ensure that Puppet chooses to
apply them in an order that works.  It is in your best interest to
define all the real application-order relationships, but to avoid
defining other relationships (e.g. to force exactly one order of
application among several viable ones).  The tools for defining
application-order relationships are the ''require'',
''before'',
''subscribe'', and ''notify'' resource
metaparameters, the arrow syntax
for declaring relationships, and the ''require'' function.

2) It''s not clear to me whether the various options you envision for
usage of class nginx are intended to be exclusive alternatives.  If
any node might need to use more than one of them then your concept
cannot work as you imagine.

3) Here''s a skeleton for something that should work more or less along
the lines you describe:

### nginx module ###

# external classes
# nodes and classes from other modules
# may declare one or more of these:

class nginx::default {
  # Note: the relative order of the ''include''
  # statements is not significant
  include ''nginx::base''
  include ''nginx::conf''
}

class nginx::ruby {
  include ''nginx::base''
  include ''nginx::extras''
  include ''nginx::conf''
  include ''nginx::passenger''
}

class nginx::php {
  include ''nginx::base''
  include ''php::base''
  include ''nginx::conf''
  include ''nginx::conf::php''
}

# internal classes
# nodes and classes from other modules
# should not declare any of these directly:

class nginx::base {
  package { ''nginx'': }
}

class nginx::conf {
  include ''nginx::base''
  some_type_that_configures_nginx { ''conf_name'':
    require => Package[''nginx'']
  }
  # Note: some people would prefer a class-level
  # relationship to the above resource-level one.
  # Either can work.
}

class nginx::extras {
  include ''nginx::base''

  package { ''nginx-extras'':
    require => Package[''nginx'']
    before => Some_type_that_configures_nginx[ ''conf_name'']
  }
}

class nginx::conf::passenger {
  include ''nginx::conf''
  include ''nginx::extras''

  some_type_that_configures_nginx_for_passenger {
    ''nginx_passenger_conf_name'':
    require => Some_type_that_configures_nginx[''conf_name'']
  }
}

class nginx::conf::php {
  include ''nginx::conf''
  require ''php::base''

  some_type_that_configures_nginx_for_php {
    ''nginx_php_conf_name'':
    require => Some_type_that_configures_nginx[''conf_name'']
  }
}

### php module ###

class php::base {
  package { ''php5-fpm'': }
}


##############

4) There are other ways to do it, including some involving class
parameterization.


John

-- 
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 Nov 2, 9:19 am, jcbollinger <John.Bollin...@stJude.org>
wrote:
> 1) You do not need flow control, which is good because Puppet does not
> offer it.  [...]

Puppet does offer various conditionals, however, that might look like
flow control to you.  I supposed you knew the basics of Puppet DSL
because you said you already had a working Puppet setup, but perhaps
that''s not a safe assumption.  Do read the Puppet Language Guide
(http://docs.puppetlabs.com/guides/language_guide.html) if you have
not already done so.


John

-- 
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.