[Puppet Users] Proposals for modules naming conventions

[Al @ Lab42]

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 :-)

2- distinct names for client and server, where applicable (IE:
samba::client , samba::server)

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,
  }
}

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.

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"
}

5- Specific variations on the normal behaviour of an application
should be specified as subclasses (IE: samba::pdc or samba::ldap)

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,
  }
}

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",
        }
[....]
}

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.


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.

My 2c
Al

--

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.