Hi Al, Welcome back, great post!
+1, except for (as predicted) #8, where I think that the rationale doesn't make sense, especially if one wants to start configuring modules via facter and/or external nodes. prefixing with the module name would make more sense for me. Regards, DavidS On 17.12.2009 17:15, 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 :-) > > 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. > > > -- 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.
