Best practice to manage multi-OS for the same module?

[DEGREMONT Aurelien]

Hello all,

As said in the subject, I did not find in puppet doc the official
recommendation in how multi-os should be handled in module manifests.

Let's say I want my module foo having classes that could be used on
Debian, RHEL6 and Fedora 10 to 18.
What would be the recommended way to manage differences between all of
these systems?

I know there is conditionals usable in classes, but is this the
recommended way?

Also, when I decommission" Fedora10" by example, and I do not want to
manage it in all my modules anymore, as this is unneeded complexity, I
need to modify all the "if" statement in all modules to remove fedora10
special treatments?


Aur�lien

[Puppet List]

Hello

Putting the os specifics into a subclass would make locating it easy.

Moving the what is supported into hiera would make that site wide and clearer

Each os subclass could lookup and see if it is supported and if not fail

Neil

Aurélien

--
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...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[DEGREMONT Aurelien]

Le 24/10/2013 13:23, Puppet List a �crit :

>
> Hello
>
> Putting the os specifics into a subclass would make locating it easy.
>

OK

>
> Moving the what is supported into hiera would make that site wide and
> clearer
>
> Each os subclass could lookup and see if it is supported and if not fail
>

I do not see what you mean here...


Aur�lien

[Rahul Khengare]

Hello Aurélien,

     You can write the puppet manifests in a such way that it execute specific resources for particular OS.

Puppet variables, conditional statements like IF, CASE, SELECTOR and FACTS helps you to write the conditional manifests.

Refer following links to understand how to manage or write the conditional puppet manifests, 

1. http://docs.puppetlabs.com/learning/variables.html

2. http://docs.puppetlabs.com/puppet/2.7/reference/lang_conditional.html

Hope this will help to achieve your goal.

Thanks and Regards,

Rahul Khengare,

NTT DATA OSS Center, Pune, India.

Aur�lien

[Jason Antman]

Aur�lien,

I'm a fan of the params.pp pattern, as is used in a lot of puppetlabs'
own modules. Most of the current modules use parameterized classes, so
if you're using a less-capable ENC (like the current Puppet Dashboard /
Console, ironically) you'll need to write wrapper classes.

To see what I'm referring to, look at the puppetlabs-puppet module,
specifically:
https://github.com/puppetlabs/puppetlabs-puppet/blob/master/manifests/init.pp
and
https://github.com/puppetlabs/puppetlabs-puppet/blob/master/manifests/params.pp

The classes that are directly used (like 'puppet' itself, in init.pp)
are parameterized, inherit puppet::params, and use
$puppet::params::VariableName as defaults which can be overridden.
Inside of puppet::params, there is a case statement that sets variables
based on operatingsystem (or other facts, or combinations).

You can certainly do this without *needing* the parameterized classes,
just by requiring a params subclass, and setting your os-specific
defaults there. I really like this pattern because:
- it keeps big multi-branch conditionals in one place, instead of
scattered around your code
- it provides one place to look to confirm which OSes the module supports
- it provides one place to go to extend the module for new OSes

-Jason Antman

[DEGREMONT Aurelien]

Le 26/10/2013 16:18, Jason Antman a �crit :

> Aur�lien,
>
> I'm a fan of the params.pp pattern, as is used in a lot of puppetlabs'
> own modules. Most of the current modules use parameterized classes, so
> if you're using a less-capable ENC (like the current Puppet Dashboard /
> Console, ironically) you'll need to write wrapper classes.
>
> To see what I'm referring to, look at the puppetlabs-puppet module,
> specifically:
> https://github.com/puppetlabs/puppetlabs-puppet/blob/master/manifests/init.pp
> and
> https://github.com/puppetlabs/puppetlabs-puppet/blob/master/manifests/params.pp
>
> The classes that are directly used (like 'puppet' itself, in init.pp)
> are parameterized, inherit puppet::params, and use
> $puppet::params::VariableName as defaults which can be overridden.
> Inside of puppet::params, there is a case statement that sets variables
> based on operatingsystem (or other facts, or combinations).
>
> You can certainly do this without *needing* the parameterized classes,
> just by requiring a params subclass, and setting your os-specific
> defaults there. I really like this pattern because:
> - it keeps big multi-branch conditionals in one place, instead of
> scattered around your code
> - it provides one place to look to confirm which OSes the module supports
> - it provides one place to go to extend the module for new OSes

I agree with you as long as a different OS does not require something
really different than the other ones.
As long as you only need to change package/service names, or few file
path, that's easy.

Let's say that a tool on OS 'A' needs 10 packages and 1 service to be
operational and on OS 'B', it just needs 5 config files (for some
totally unknown reason, just an example).
In this case, configuring this service with a list of variable in
params.pp won't do the trick.

You will need a couple of 'if' in your main classes. That means that one
day, when you will drop OS 'B' support, you will have to modify all your
classes and this will be the uneasy path I would like to avoid.



Aur�lien