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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
David Schmitt
2009-Dec-17 16:28 UTC
Re: [Puppet Users] Proposals for modules naming conventions
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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Michael Gliwinski
2009-Dec-17 17:55 UTC
Re: [Puppet Users] Proposals for modules naming conventions
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 support@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Al @ Lab42
2009-Dec-17 18:58 UTC
[Puppet Users] Re: Proposals for modules naming conventions
Thanks for feedback,> > 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.Well, you generally have different values for package/service names and configuration files paths. When differences are wide enough (IE: apache) point 4 is definitively the best, but in most cases I find the above variations more clear if defined where they are used. But this is really a matter of taste, and doesn''t affect the general logic (no need for separated modules when differences are few).> > 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?Ya, you''re are right. If there is a samba::server there should be a samba::server::pdc.> > 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.That''s a point, but it actually doesn''t affect the naming convention, but how singular lines modifications are implemented. At the moment I prefer to use augeas on a puppet generated file of "augeas commands", that is served as a file resource and subscribes an exec that runs augeas using that file as a "source" (this has the advantage that you can use augeas on a file in an arbitrary path, which is currently still not possibile, even if a patch on the augeas type for this is already done and ready the the next release). In any case, HOW you manage to get the line configured is not what I wanted to discuss (even if this is always a very interesting and challenging topic), I just seek for naming standards ;-)> > 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.I retire my proposal. What you''ve written, and DavidS has confirmed, is probaly more suitable (and it''s actually what I used to do, some time ago :-! ) All the best 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Al @ Lab42
2009-Dec-17 19:19 UTC
[Puppet Users] Re: Proposals for modules naming conventions
On 17 Dic, 17:28, David Schmitt <da...@dasz.at> wrote:> 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, DavidSHi David, thanks for the reply. You and Michael have definitively convinced me about variable name namings (modulename_ is surely a better prefix). I take the occasion of your reply to discuss deeper a topic that I''ve always found somehow controversial. Many use to say, if I''ve understood well, that in a puppet infrastructure there should only be variables generated by facts, that it''s not a good idea to define custom variables at node''s level (or using different ways to group/classify them). I can understand this if we talk about external nodes, when you can have powerful and easy ways to aggregate/define variables for nodes (and still they are not fact variables), but I still have to understand why and how it should be better to define variables necessary for your classes (for example an external server where to send syslog messages, which changed according to different servers'' locations or test/prod status or whatever logic) in a fact. I find more difficult to write and control this logic in custom facts splattered in different modules, rather that in a single "infrastructural" class where all variables are defined according to custom logic and groupings, or, as I generally do, in a nodes'' inheritance structure, where there are intermediate node that can define networks or geographical locations or whatever groups that are inherited by host nodes. Excuse my ignorance, if someone can enlighten and convince me on the advantages of placing the logic of a puppet infrastructure in facts, please do it. I like to redefine my beliefs :-D 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Scott Smith
2009-Dec-17 19:51 UTC
Re: [Puppet Users] Proposals for modules naming conventions
Al @ Lab42 wrote:> 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 :-) >Hmm, I think most of the conventions are sensible, thanks for taking the time to summarize it all! On point #1 however, I kind of disagree: Technically Apache (Software Foundation) is the organization, and the web server is Apache HTTP Server. I do agree that `httpd'' is way too generic. In this case I prefer to use `apache::httpd'' and `apache::tomcat'' etc. Just my opinion :) -scott -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
R.I.Pienaar
2009-Dec-17 21:01 UTC
Re: [Puppet Users] Re: Proposals for modules naming conventions
--- R.I.Pienaar On 17 Dec 2009, at 19:19, "Al @ Lab42" <lab42.it@gmail.com> wrote:> On 17 Dic, 17:28, David Schmitt <da...@dasz.at> wrote: > > I find more difficult to write and control this logic in custom facts > splattered in different modules, rather that in a single > "infrastructural" class where all variables are defined according to > custom logic and groupings, or, as I generally do, in a nodes'' > inheritance structure, where there are intermediate node that can > define networks or geographical locations or whatever groups that are > inherited by host nodes. > > Excuse my ignorance, if someone can enlighten and convince me on the > advantages of placing the logic of a puppet infrastructure in facts, > please do it. > I like to redefine my beliefs :-D >I use extlookup with sane defaults for any and all configurable variables in classes, it makes all of this easier Julian Simpson is hacking on extlookup at the moment we should soon have a pligins system so you can replace csv with whatever you like, there is some support from RL which suggests it will make it into puppet base when we are done with this process> > -- > > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Julian Simpson
2009-Dec-17 21:04 UTC
Re: [Puppet Users] Proposals for modules naming conventions
Was there discussion on metadata for modules? I know Luke was experimenting with that. I''d love to see what OS(es) a module has been tested on, and what versions of Puppet. J. PS: WRT to RI Peinaar''s mail: any votes on extlookup backends? Once I have extracted the CSV code it should be simple to add more. I''m thinking yaml or json, or something like that. 2009/12/17 Scott Smith <scott@ohlol.net>:> Al @ Lab42 wrote: >> 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 :-) >> > > Hmm, I think most of the conventions are sensible, thanks for taking the time to summarize it all! > > On point #1 however, I kind of disagree: Technically Apache (Software Foundation) is the > organization, and the web server is Apache HTTP Server. I do agree that `httpd'' is way too generic. > In this case I prefer to use `apache::httpd'' and `apache::tomcat'' etc. > > Just my opinion :) > > -scott > > -- > > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > > >-- Julian Simpson Software Build and Deployment http://www.build-doctor.com http://twitter.com/builddoctor -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Michael Gliwinski
2009-Dec-18 09:21 UTC
Re: [Puppet Users] Re: Proposals for modules naming conventions
On Thursday 17 December 2009 18:58:50 Al @ Lab42 wrote:> > > 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. > > That''s a point, but it actually doesn''t affect the naming convention, > but how singular lines modifications are implemented. > At the moment I prefer to use augeas on a puppet generated file of > "augeas commands", that is served as a file resource and subscribes an > exec that runs augeas using that file as a "source" (this has the > advantage that you can use augeas on a file in an arbitrary path, > which is currently still not possibile, even if a patch on the augeas > type for this is already done and ready the the next release). > In any case, HOW you manage to get the line configured is not what I > wanted to discuss (even if this is always a very interesting and > challenging topic), I just seek for naming standards ;-)Ah, yes, I got carried away there ;P Naming is definitely OK there, apart from maybe using openssh instead of ssh (in this particular example) as per your suggestion.> > > 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. > > I retire my proposal. > What you''ve written, and DavidS has confirmed, is probaly more > suitable (and it''s actually what I used to do, some time ago :-! )Cool. I mostly use it to prevent clashes with variables for other modules/classes but I think it would most likely also handle facter variables. ********************************************************************************************** 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 support@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
David Schmitt
2009-Dec-18 09:30 UTC
Re: [Puppet Users] Proposals for modules naming conventions
On 17.12.2009 18:55, Michael Gliwinski wrote:>> 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.If there is a performance problem augeas[1] needs to learn batching. Resources and defines are already hashes. Using another layer of hashes on top of hashes to work around an implementation detail is just awful. Regards, DavidS [1] and package providers and everybody else. This was already discussed a few months ago. Doing it right requires a major restructuring of the puppet executor but will bring benefits without compromising puppet''s datamodel -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Al @ Lab42
2009-Dec-18 16:19 UTC
[Puppet Users] Re: Proposals for modules naming conventions
On 17 Dic, 20:51, Scott Smith <sc...@ohlol.net> wrote:> Al @ Lab42 wrote: > > 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 :-) > > Hmm, I think most of the conventions are sensible, thanks for taking the time to summarize it all! > > On point #1 however, I kind of disagree: Technically Apache (Software Foundation) is the > organization, and the web server is Apache HTTP Server. I do agree that `httpd'' is way too generic. > In this case I prefer to use `apache::httpd'' and `apache::tomcat'' etc. > > Just my opinion :) > > -scottRight point. I actually would prefer, at this point, httpd rather than apache::httpd, also because otherwise for coherency we should somehow always define the makers of the software. Maybe we could just try to make a list of possible "standardized" modules names, at least for the dubious cases: openssh or ssh? apache or httpd or apache::httpd? dashboard or puppet::dashboard or puppet::nodemanager? ;-) I can''t imagine now more similar dubious cases, but surely there are. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Al @ Lab42
2009-Dec-18 16:59 UTC
[Puppet Users] Re: Proposals for modules naming conventions
On 17 Dic, 22:04, Julian Simpson <simpsonjul...@gmail.com> wrote:> Was there discussion on metadata for modules? I know Luke was > experimenting with that. I''d love to see what OS(es) a module has > been tested on, and what versions of Puppet. >Yes there has been discussion, that''s another important point, I started this: http://groups.google.com/group/puppet-users/t/f2fdc84e423c7768 to summarize and discuss modules metadata. This and naming standards are both releant topics, for me, and maybe is better to keep them divided in order to reach, somehow, a sythesis on both. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Luke Kanies
2009-Dec-18 19:31 UTC
Re: [Puppet Users] Re: Proposals for modules naming conventions
On Dec 17, 2009, at 11:19 AM, Al @ Lab42 wrote:> On 17 Dic, 17:28, David Schmitt <da...@dasz.at> wrote: >> 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 > > Hi David, > thanks for the reply. > You and Michael have definitively convinced me about variable name > namings (modulename_ is surely a better prefix). > > I take the occasion of your reply to discuss deeper a topic that I''ve > always found somehow controversial. > Many use to say, if I''ve understood well, that in a puppet > infrastructure there should only be variables generated by facts, that > it''s not a good idea to define custom variables at node''s level (or > using different ways to group/classify them). > I can understand this if we talk about external nodes, when you can > have powerful and easy ways to aggregate/define variables for nodes > (and still they are not fact variables), but I still have to > understand why and how it should be better to define variables > necessary for your classes (for example an external server where to > send syslog messages, which changed according to different servers'' > locations or test/prod status or whatever logic) in a fact. > > I find more difficult to write and control this logic in custom facts > splattered in different modules, rather that in a single > "infrastructural" class where all variables are defined according to > custom logic and groupings, or, as I generally do, in a nodes'' > inheritance structure, where there are intermediate node that can > define networks or geographical locations or whatever groups that are > inherited by host nodes. > > Excuse my ignorance, if someone can enlighten and convince me on the > advantages of placing the logic of a puppet infrastructure in facts, > please do it. > I like to redefine my beliefs :-DI''m playing a bit of catch-up on this thread, so bear with me as I work through it. First, to address using variables for logic: I would never recommend anyone rely entirely on facts for configuration - quite the opposite, I would recommend people *only* use facts for cases where the client is the only host capable of generating or discovering a given piece of data. For instance, I think it''s bad form to send a fact to the client whose value is static or relies on a database (or data file) also distributed with the fact. I think server-side functions (usually doing a DB call) is a much better choice. I see, at the least, these sources of data: 1) Client facts -- discoverable and/or calculable only on the client 2) Declared client data -- declared in external node tools by a human, per-node or per-server class etc. 3) Dynamic data -- retrieved with an extlookup-style function or equivalent which essentially uses a db backend for all of its data but has some understanding of class logic that can selectively load data Then, of course, you have essentially internal temporary variables whose value entirely derives from one of these three sources. Any attempt to push any of these behaviours into a different data type will hurt. Obviously we have to answer this question in terms of standards, but for me the more interesting question is how we should develop Puppet going forward. It''s obvious to all of us that Puppet doesn''t perfectly solve all of these problems, and I''d much rather fix those issues than calcify standards that work around fixable problems. Here are some steps I think we need to take that will help this considerably: 1) Consider any system running without an external node tool to be in a degraded mode. That is, you''ve chosen to forego an entire data type in your system, so you''ve got less functionality. There are now multiple functional external node tools, one of them supported by Reductive Labs, so there''s no good reason not to at least plan on using one in the near future. 2) Integrate an extlookup-like functionality directly into Puppet classes. This has been discussed a bit, but no real design has been proposed, much less decided upon. I''d like some kind of data interface that can support multiple backends and then have classes automatically look their data up, rather than having to trigger the lookup as functions currently require. There are some other features I think we need, but I''ll add them to my response to the opening email because they''re less data-focused. -- There is nothing so useless as doing efficiently that which should not be done at all. -- Peter Drucker --------------------------------------------------------------------- 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Luke Kanies
2009-Dec-18 19:46 UTC
Re: [Puppet Users] Proposals for modules naming conventions
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 proposalsIt''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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Luke Kanies
2009-Dec-18 20:25 UTC
Re: [Puppet Users] Re: Proposals for modules naming conventions
On Dec 17, 2009, at 1:01 PM, R.I.Pienaar wrote:> > > --- > R.I.Pienaar > > On 17 Dec 2009, at 19:19, "Al @ Lab42" <lab42.it@gmail.com> wrote: > >> On 17 Dic, 17:28, David Schmitt <da...@dasz.at> wrote: >> >> I find more difficult to write and control this logic in custom facts >> splattered in different modules, rather that in a single >> "infrastructural" class where all variables are defined according to >> custom logic and groupings, or, as I generally do, in a nodes'' >> inheritance structure, where there are intermediate node that can >> define networks or geographical locations or whatever groups that are >> inherited by host nodes. >> >> Excuse my ignorance, if someone can enlighten and convince me on the >> advantages of placing the logic of a puppet infrastructure in facts, >> please do it. >> I like to redefine my beliefs :-D >> > > > I use extlookup with sane defaults for any and all configurable > variables in classes, it makes all of this easier > > Julian Simpson is hacking on extlookup at the moment we should soon > have a pligins system so you can replace csv with whatever you > like, there is some support from RL which suggests it will make it > into puppet base when we are done with this processI''ve always supported this functionality in Puppet, but I think a function is the wrong long-term solution. However, until we come up with something better, I''m happy to accept extlookup into it, as long as (as planned) something other than CVS is supported as a backend. I''ve just opened a ticket for this feature: http://projects.reductivelabs.com/issues/2953 I''ll open a thread on -dev about how to define this functionality. Plus some other tickets related to this whole thread: http://projects.reductivelabs.com/issues/2954 http://projects.reductivelabs.com/issues/2955 http://projects.reductivelabs.com/issues/2956 And maybe: http://projects.reductivelabs.com/issues/2957 -- Sapolsky''s First Law: Think logically, but orthogonally. --------------------------------------------------------------------- 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Al @ Lab42
2009-Dec-19 17:46 UTC
[Puppet Users] Re: Proposals for modules naming conventions
On 18 Dic, 20:46, Luke Kanies <l...@madstop.com> wrote:> 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 inhttp://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.That''s interesting, +1> > > # 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.+1 It seems like the uprising of usable web interfaces and external nodes management tools such as the Foreman and the Dahsboard is going to affect the same Puppet evolution. What is clear is that people are building infrastructures following different approaches and logics. The language is already enough flexible to allow this, and further developments as the ones you''ve indicated, will enhance alternatives but also, maybe, help in some kind of standardization.> > 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.Alternatives?> > > 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. :)Still I''m wondering how to name variables that are not related to a single class but are somehow more general. I know that it''s a questionable approach, but I still find variables as $my_zone (indicating basically the network where the node is, or anyway, a grouping logic) or $my_role (indicating the function of the node, such as webserver, dabasase ...) very useful to manage different files or variables sets for different cases. How am I supposed to call them? Should I stop to use them? Even using external nodes you group nodes according to similar logics and besides setting variables you may want, for example to source different files accoring to different groups.> > > 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.Yes, the possibility to integrate and/or exchange modules from different sources, or to plug them seamlessly in an existing infrastructure is something to work on. For example now if you get modules from a source, you inherit some custom choices (for example the monitoring logic) that won''t work without modification with modules from other sources. I was thinking if it''s worth to agree on some standard for typical cross-node operations such as, for example, monitoring or backup. I imagine at least 2 approaches: 1- Standard named subclasses Something like an httpd::monitor class, that is included where necessary and doesn''t inherit anything, so that it can be somehow independent from different httpd classes, where you define what and how to monitor your service. What is inside this class can change according to custom logic, coherent in your puppet infrastructure, but at least you know that here and only here you find all the stuff related to monitoring, so you can adapt it to your monitoring layout and needs. Something similar might be done for example in httpd::backup to define and manage backup logic 2- Custom types with standard names I''d love to place in my modules a sort of "custom but with standard name" type "Backup", that defines what to backup, whatever my backup system is. Something that would look like: backup { "wwwdata": path => $operatingsystem ?{ default => "/var/www/html", }, } what the backup define does is then left to custom approaches according to the backup methods and tools used. Something like this can be expanded for other needs, such as auditing and monitoring. A rushed down example (I feel like also this won''t be liked by many :-) : class apache::managed { $apache_processname = $operatingsystem ?{ default => "httpd", }, $apache_port = "80" $apache_data = $operatingsystem ?{ default => "/var/www/html", }, backup { "wwwdata": frequency => daily, path => $apache_data, enabled => "yes", } monitor { "Port_$apache_port": type => "port", proto => "tcp", port => $apache_port, address => "localhost", enabled => "yes", } monitor { "Service_$apache_processname": type => "process", name => $apache_processname, enabled => "yes", } audit { "Service_$apache_processname": type => "process", name => $apache_processname, } docs { "Apache_Documentation": url => "http://httpd.apache.org", } docs { "Our Company Apache Hardenings": url => "http://www.mycompany.lan/apachehardenings/", } } Here, what docs, monitor, backup, audit do can be adapted and managed in different ways, but if there''s agreement on naming conventions (and possibly some minimal necessary extra parameters) some module interchangeability on elements that are usually never managed in the same way can be reached. Whatever the approach , what is to avoid, IMHO, is to place, in a general application class, something that can work only if you have other modules of the same set (besides eventually a common module with custom types as, for example the ones to manipulate and rebuild file contents (IE: DavidS'' replaceline configfile ecc.)). As far as I''ve seen up to now, this applies especially to monitoring stuff. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Luke Kanies
2009-Dec-21 18:24 UTC
Re: [Puppet Users] Re: Proposals for modules naming conventions
On Dec 19, 2009, at 9:46 AM, Al @ Lab42 wrote:> On 18 Dic, 20:46, Luke Kanies <l...@madstop.com> wrote: >> 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 inhttp://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. > > That''s interesting, +1 > >>>> # 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. > > +1 > It seems like the uprising of usable web interfaces and external nodes > management tools such as the Foreman and the Dahsboard is going to > affect the same Puppet evolution. > What is clear is that people are building infrastructures following > different approaches and logics. > The language is already enough flexible to allow this, and further > developments as the ones you''ve indicated, will enhance alternatives > but also, maybe, help in some kind of standardization. > >>> 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. > > Alternatives?Not really, but the problem exists so we need to find a way to model it. For me, I''d rather find a good model and support it directly in Puppet. I know we can''t easily do that in the short, so we have to struggle with this kind of thing, but if we can stay conscious of our ability to enhance Puppet and try to come up with a modeled solution, we''ll all be happier.>>>> 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. :) > > Still I''m wondering how to name variables that are not related to a > single class but are somehow more general. > I know that it''s a questionable approach, but I still find variables > as $my_zone (indicating basically the network where the node is, or > anyway, a grouping logic) or $my_role (indicating the function of the > node, such as webserver, dabasase ...) very useful to manage different > files or variables sets for different cases. > How am I supposed to call them? Should I stop to use them? Even using > external nodes you group nodes according to similar logics and besides > setting variables you may want, for example to source different files > accoring to different groups.I''m not really sure what you mean. On this note, I believe we''re planning on adding scoped variables to the external node interface in the near future -- you could set ''$apache::port'' in your external node tool, and your ''apache'' class would automatically get ''$port'' set in its scope. Does that cover what you want, or is it unrelated?>>> 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. > > Yes, the possibility to integrate and/or exchange modules from > different sources, or to plug them seamlessly in an existing > infrastructure is something to work on. > For example now if you get modules from a source, you inherit some > custom choices (for example the monitoring logic) that won''t work > without modification with modules from other sources. > I was thinking if it''s worth to agree on some standard for typical > cross-node operations such as, for example, monitoring or backup. > > I imagine at least 2 approaches: > 1- Standard named subclasses > Something like an httpd::monitor class, that is included where > necessary and doesn''t inherit anything, so that it can be somehow > independent from different httpd classes, where you define what and > how to monitor your service. What is inside this class can change > according to custom logic, coherent in your puppet infrastructure, but > at least you know that here and only here you find all the stuff > related to monitoring, so you can adapt it to your monitoring layout > and needs. > Something similar might be done for example in httpd::backup to define > and manage backup logic > > 2- Custom types with standard names > I''d love to place in my modules a sort of "custom but with standard > name" type "Backup", that defines what to backup, whatever my backup > system is. Something that would look like: > backup { > "wwwdata": > path => $operatingsystem ?{ > default => "/var/www/html", > }, > } > > what the backup define does is then left to custom approaches > according to the backup methods and tools used. > Something like this can be expanded for other needs, such as auditing > and monitoring.I like both of these, but given how rarely it''s come up for us yet, I''m more comfortable letting people experiment with it for a while and try to extract a standard from a bunch of practice, rather than guess how it will go.> A rushed down example (I feel like also this won''t be liked by > many :-) : > > class apache::managed { > > $apache_processname = $operatingsystem ?{ > default => "httpd", > }, > $apache_port = "80" > $apache_data = $operatingsystem ?{ > default => "/var/www/html", > }, > > > backup { > "wwwdata": > frequency => daily, > path => $apache_data, > enabled => "yes", > } > > monitor { > "Port_$apache_port": > type => "port", > proto => "tcp", > port => $apache_port, > address => "localhost", > enabled => "yes", > } > > monitor { > "Service_$apache_processname": > type => "process", > name => $apache_processname, > enabled => "yes", > } > > audit { > "Service_$apache_processname": > type => "process", > name => $apache_processname, > } > > docs { > "Apache_Documentation": > url => "http://httpd.apache.org", > } > > docs { > "Our Company Apache Hardenings": > url => "http://www.mycompany.lan/apachehardenings/", > } > > } > > Here, what docs, monitor, backup, audit do can be adapted and managed > in different ways, but if there''s agreement on naming conventions (and > possibly some minimal necessary extra parameters) some module > interchangeability on elements that are usually never managed in the > same way can be reached. > > > Whatever the approach , what is to avoid, IMHO, is to place, in a > general application class, something that can work only if you have > other modules of the same set (besides eventually a common module with > custom types as, for example the ones to manipulate and rebuild file > contents (IE: DavidS'' replaceline configfile ecc.)). > As far as I''ve seen up to now, this applies especially to monitoring > stuff.I agree. Definitely giving me a lot to think about. -- Never confuse movement with action. -- Ernest Hemingway --------------------------------------------------------------------- Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Al @ Lab42
2009-Dec-29 14:44 UTC
[Puppet Users] Re: Proposals for modules naming conventions
> >>> 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. :) > > > Still I''m wondering how to name variables that are not related to a > > single class but are somehow more general. > > I know that it''s a questionable approach, but I still find variables > > as $my_zone (indicating basically the network where the node is, or > > anyway, a grouping logic) or $my_role (indicating the function of the > > node, such as webserver, dabasase ...) very useful to manage different > > files or variables sets for different cases. > > How am I supposed to call them? Should I stop to use them? Even using > > external nodes you group nodes according to similar logics and besides > > setting variables you may want, for example to source different files > > accoring to different groups. > > I''m not really sure what you mean. > > On this note, I believe we''re planning on adding scoped variables to > the external node interface in the near future -- you could set > ''$apache::port'' in your external node tool, and your ''apache'' class > would automatically get ''$port'' set in its scope. Does that cover > what you want, or is it unrelated?It''s not related (my case is for variables not directory related to a module, that I use to group hosts according to function (role) or network (zone) and are useful for setting groups of other variables or providing different configurations according to zone/role) but it''s an interesting news.> >>> 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. > > > Yes, the possibility to integrate and/or exchange modules from > > different sources, or to plug them seamlessly in an existing > > infrastructure is something to work on. > > For example now if you get modules from a source, you inherit some > > custom choices (for example the monitoring logic) that won''t work > > without modification with modules from other sources. > > I was thinking if it''s worth to agree on some standard for typical > > cross-node operations such as, for example, monitoring or backup. > > > I imagine at least 2 approaches: > > 1- Standard named subclasses > > Something like an httpd::monitor class, that is included where > > necessary and doesn''t inherit anything, so that it can be somehow > > independent from different httpd classes, where you define what and > > how to monitor your service. What is inside this class can change > > according to custom logic, coherent in your puppet infrastructure, but > > at least you know that here and only here you find all the stuff > > related to monitoring, so you can adapt it to your monitoring layout > > and needs. > > Something similar might be done for example in httpd::backup to define > > and manage backup logic > > > 2- Custom types with standard names > > I''d love to place in my modules a sort of "custom but with standard > > name" type "Backup", that defines what to backup, whatever my backup > > system is. Something that would look like: > > backup { > > "wwwdata": > > path => $operatingsystem ?{ > > default => "/var/www/html", > > }, > > } > > > what the backup define does is then left to custom approaches > > according to the backup methods and tools used. > > Something like this can be expanded for other needs, such as auditing > > and monitoring. > > I like both of these, but given how rarely it''s come up for us yet, > I''m more comfortable letting people experiment with it for a while and > try to extract a standard from a bunch of practice, rather than guess > how it will go.You are probably right, even if I would like to receive some opinions and suggestions from other modules writers. I find somehow crucial the possibility to somehow find "interoperability standards" between module sets in order to ease integration and incorporation of other modules in a custom set.> > A rushed down example (I feel like also this won''t be liked by > > many :-) : > > > class apache::managed { > > > $apache_processname = $operatingsystem ?{ > > default => "httpd", > > }, > > $apache_port = "80" > > $apache_data = $operatingsystem ?{ > > default => "/var/www/html", > > }, > > > backup { > > "wwwdata": > > frequency => daily, > > path => $apache_data, > > enabled => "yes", > > } > > > monitor { > > "Port_$apache_port": > > type => "port", > > proto => "tcp", > > port => $apache_port, > > address => "localhost", > > enabled => "yes", > > } > > > monitor { > > "Service_$apache_processname": > > type => "process", > > name => $apache_processname, > > enabled => "yes", > > } > > > audit { > > "Service_$apache_processname": > > type => "process", > > name => $apache_processname, > > } > > > docs { > > "Apache_Documentation": > > url => "http://httpd.apache.org", > > } > > > docs { > > "Our Company Apache Hardenings": > > url => "http://www.mycompany.lan/apachehardenings/", > > } > > > } > > > Here, what docs, monitor, backup, audit do can be adapted and managed > > in different ways, but if there''s agreement on naming conventions (and > > possibly some minimal necessary extra parameters) some module > > interchangeability on elements that are usually never managed in the > > same way can be reached. > > > Whatever the approach , what is to avoid, IMHO, is to place, in a > > general application class, something that can work only if you have > > other modules of the same set (besides eventually a common module with > > custom types as, for example the ones to manipulate and rebuild file > > contents (IE: DavidS'' replaceline configfile ecc.)). > > As far as I''ve seen up to now, this applies especially to monitoring > > stuff. > > I agree. Definitely giving me a lot to think about.Glad to hear that. 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.