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-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.
