On Dec 17, 2009, at 8:15 AM, 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
It's great that you've started this discussion. We're finally making
progress on enhancing the modules, both from the perspective of the
language (adding metadata, etc.) and from the management perspective
(Bruce Williams is leading the team working on a module forge).
> 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)
I agree with both of these.
> 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"
> }
> }
I'd love to see this broken out into a constant-like functionality in
the class. I think rowlf or the release after it will support class
attributes again (yay!), and this should work at that point:
class ssh::server($sshservice = $operatingsystem ? {["freebsd",
"openbsd"] => "sshd, default => "ssh" }) { ... }
Or something similar. You're using logic, so it's not trivially
introspectable like a straight constant would be, but at least you've
declared that the class uses this attribute and that it's calculated
rather than set internally.
> # 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.
I think these are fine solutions in the short term, but they're more
an indication of poor expressiveness in the language than they are a
real solution. I want to be able to specify, at parse-time, which
platforms a given class works for, and we're now at the point where we
can start to add that ability. For instance, this syntax doesn't work
right now but it could now be added relatively easily (on top of the
code for #2596[1]:
class apache supports($operatingsystem => [solaris, debian]) { ... }
There's obviously a lot of work to do to figure out what you want to
specify and how it works. This is syntactically similar to parameters
in definitions but functionally equivalent to our common 'confine'
usage, so I'd like to find a way to use that term.
The things I prefer about this syntax is that it's declared as data
rather than in the logic of the class, and it's queryable at parse-
time. This means we could, for instance, throw an exception if anyone
tried to use the class on an unsupported platform. Of course, in most
cases you'd want to just warn in such a case, rather than fail, but
there are definitely cases where you'd want to fail instead.
As this integrates into the dashboard and similar tools, you get even
more power - the console for connecting a node with a class could give
you this same information -- 'class apache is only supported on debian
and rhel, so you have to choose one of those as the platform if you
want that class'. It'd also be easy to run a report on this kind of
information.
> 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)
As discussed, these two rules together essentially lead to chaos.
You've got two dimensions for breaking classes apart, and now you're
in trouble.
> 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.
Glad you retracted this. :)
> 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.
I think this is a relatively good starting point. There are a bunch
of areas that it doesn't yet cover -- e.g., the whole problem of
managing modules written by others, such as what to do when two people
have produced a module with the same name. A lot of those will come
out as the module forge starts to develop.
1 - http://projects.reductivelabs.com/issues/2596
--
Men never do evil so completely and cheerfully as when they do it from a
religious conviction. --Blaise Pascal
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--
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.
