Puppet users - Oct 2013 - Best practice to manage multi-OS for the same module?

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

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

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
On 24 Oct 2013 11:13, "DEGREMONT Aurelien"
<aurelien.degremont@cea.fr>
wrote:
> 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
>
> --
> 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<puppet-users%2Bunsubscribe@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<http://groups.google.com/group/puppet-users>
> .
> For more options, visit
https://groups.google.com/**groups/opt_out<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.
For more options, visit https://groups.google.com/groups/opt_out.

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

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

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.


On Thursday, October 24, 2013 3:43:34 PM UTC+5:30, Aurélien Degrémont
wrote:
>
> 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 
>
-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

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

On 10/24/2013 06:13 AM, DEGREMONT Aurelien wrote:
> 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
>
-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

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

-- 
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/52713EFD.9090101%40cea.fr.
For more options, visit https://groups.google.com/groups/opt_out.