> >>> 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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
