Hi,
On Thursday 17 December 2009 16:15:17 Al @ Lab42 wrote:
> Hallo *,
> at the Puppet Camp there has been some discussion about modules
> standards and naming conventions.
> I might have missed some relevant bits in the last months of personal
> absence from the list so I'm not sure if this topic has evolved or has
> been discussed more deeply.
>
> I take this occasion to sum up what seem somehow the community
> standards and propose something else for, simply, the conventions we
> might try to agree on class names.
> I take as reference what is written in
> http://reductivelabs.com/trac/puppet/wiki/ModuleStandards introduction what
> are my personal proposals
>
> COMMUNITY "STANDARDS" SUM-UP (?)
>
> 1- a class for an application, sharing the same name. (IE: apache
> (not httpd) for managing Apache)
> Still I wonder why I (and many) use ssh instead of openssh :-)
+1
good point about openssh
> 2- distinct names for client and server, where applicable (IE:
> samba::client , samba::server)
+1
> 3- FROM WIKI: Operating system differences should be specified in
> variables in a case at the start of the module, as follows:
> class ssh::server {
> case $operatingsystem {
> "freebsd","openbsd": {
> $sshservice = "sshd"
> }
> debian: {
> $sshservice = "ssh"
> }
> }
> # use a constant title to facilitate stable relations
> service { "ssh::server":
> name => $sshservice,
> ensure => running,
> enable => true,
> }
> }
+1, that's what I use usually
> I personally prefer something like (not avoid unnecessary internal
> variables in modules):
> class ssh::server {
> service { "ssh::server":
> name => $operatingsystem ? {
> debian => "ssh",
> default => "sshd",
> }
> ensure => running,
> enable => true,
> }
> }
>
> but that affects the class internals and is not relevant for the name
> itself.
I still prefer the former as OS differences are encapsulated in one place.
This one may be better for really small differences.
> 4- FROM WIKI: Bigger operating system differences should be split out
> into their respective classes:
> class ssh::server::common {
> service { 'ssh::server': ... }
> }
> class ssh::server::debian inherits ssh::server::common {
> Service['ssh::server'] { name => 'ssh' }
> }
> class ssh::server {
> include "ssh::server::$operatingsystem"
> }
+1
> 5- Specific variations on the normal behaviour of an application
> should be specified as subclasses (IE: samba::pdc or samba::ldap)
How does that relate to ::server and ::client above? E.g. if samba::pdc
implies samba::server wouldn't it be better if it was samba::server::pdc?
> 6- PROPOSAL for service or application status (based mostly on what
> I've seen around).
> - If you want an application removed provide something like:
> apache::absent inherits apache {
> Package["apache"] {
> ensure => absent,
> }
> }
>
> - If you want an application stopped provide something like:
> apache::stopped inherits apache {
> Service["apache"] {
> ensure => stopped,
> }
> }
>
> - If you want an application not enable at boot time provide something
> like:
> apache::disabled inherits apache {
> Service["apache"] {
> enable => false,
> }
> }
Didn't need those yet, but makes sense.
> 7- PROPOSAL for general class configuration define (based on augeas or
> other inline modificators)
> define ssh::config ($value) {
>
> # Augeas version.
> augeas {
> "sshd_config_$name":
> context => $operatingsystem ? {
> default => "/files/etc/ssh/sshd_config",
> },
> changes => "set $name $value",
> onlyif => "get $name != $value",
> # onlyif => "match $name/*[.='$value'] size == 0",
> }
>
> # Davids' replaceline version (to fix)
> # replaceline {
> # "sshd_config_$name":
> # file => "/etc/ssh/sshd_config",
> # pattern => "$name",
> # replacement => "^$name $value",
> # }
> }
>
> This define can be used in a class like
> class ssh::eal4 {
>
> # Cripto settings
> ssh::config { Protocol:
> value => "2",
> }
>
> ssh::config { Ciphers:
> value => "3des-cbc",
> }
>
> # X11 forwarding (You MAY allow)
> ssh::config { X11Forwarding:
> value => "no",
> }
> [....]
> }
This makes sense, one problem with that however is that this creates a
resource for each option. So AFAIK for augeas that means the code (opening
the file, trying and appying changes) will be executed as many times as you
have options.
Perhaps when hashes are available using them to map (key, value) pairs to
augeas set commands would make sense.
> 8- PROPOSAL (don't think it will be widely liked): Variables names
> needed for module configuration (the ones used in templates, for
> example) should have a my_ prefix, in order to easily distinguish them
> from fact variables.
Yeah, not really ;) I do however use ${APPNAME}_ or ${CLASSNAME}_ prefix for
variables which a class treats as parameters.
> So, the point of this post is to know if there has been some agreement
> on naming standards and eventually to stir the discussion about it.
> My general idea is that if the community doesn't find a general
> agreement, a suggested standard should come from Reductive Labs, so
> that whoever is interested in sharing modules (for reusage) knows how
> to behave and, possibly, users can more easily use and integrate
> modules picked from different repositories.
Good idea. Thanks for starting this.
All the best,
Michael
**********************************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee and access to the email by anyone else
is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and
may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail
are subject to the terms and conditions expressed in the governing client
engagement leter or contract.
If you have received this email in error please notify
supp...@henderson-group.com
John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland,
BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
