Proposals for modules naming conventions
Al @ Lab42
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
David Schmitt
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
> --
>
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>
>
Michael Gliwinski
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.
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 sup...@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
*********************************************************************************
Al @ Lab42
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.
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
Al @ Lab42
> 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 :-D
al
Scott Smith
> 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
R.I.Pienaar
Julian Simpson
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 <sc...@ohlol.net>:
> --
>
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@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
Michael Gliwinski
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.
David Schmitt
>> 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
Al @ Lab42
Right 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.
Al @ Lab42
> 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.
Luke Kanies
I'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
Luke Kanies
> 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.
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
>
>
> ---
> R.I.Pienaar
>
> On 17 Dec 2009, at 19:19, "Al @ Lab42" <lab4...@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
I'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.
Al @ Lab42
> 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.
That's interesting, +1
+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?
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.
Luke Kanies
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.
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?
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.
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
Al @ Lab42
> >>> 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.
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.
Glad to hear that.
al