----- "Al @ Lab42" <[EMAIL PROTECTED]> wrote:
> Hi Digant, > what's the best place to comment/discuss what is written in: > http://www.reductivelabs.com/trac/puppet/wiki/ModuleStandards ? > > I'd like to take part in the discussion about the module standards > but > I don't think the wiki is the right places to submit ideas/remarks. > So for the moment I write here. I think this is the right place to discuss that. > > For example I find point 5 in the Modules Standards section, a bit > over engineered and not well manageable in the log term: > I don't find the necessity to introduce a new variable for every > package and service name (and pathname for almost each file served, > so > in some cases you should define a lot of variables for a module). > I would handle the operating systems differences where is necessary > with a relevant switch, like here: > > class sendmail { > > package { > sendmail: > name => $operatingsystem ? { > default => "sendmail", > }, > ensure => present; > > sendmail-cf: > name => $operatingsystem ? { > default => "sendmail-cf", > }, > ensure => present, > } > > service { sendmail: > name => $operatingsystem ? { > default => "sendmail", > }, > ensure => running, > enable => true, > hasrestart => true, > hasstatus => true, > require => Package[sendmail], > } > > file { > "sendmail.cf": > mode => 644, owner => root, group => root, > require => Package[sendmail], > ensure => present, > path => $operatingsystem ?{ > default => "/etc/mail/sendmail.cf", > }, > } > > } I think the original proposal was due to legibility. > > In any case, this is just an example (and, in this case, a solution > or > another I guess it's mostly a matter of personal taste). > Another point quite critical, according to me, is the standardization > of modules that need to manage objects provided by other modules. > An example could be a module for a software like mailcanner or amavis > or whatever: they should handle configuration files and other objects > of different other programs (for example an MTA like postfix, mail > filters like spamassassin and clamav and so on). > How can this be handled in a modular standard way (the mantainer of > mailscanner module is not necessarily the postfix mantainer)? > I've thought about different scenarios but they all require some > tweaks that can be more or less acceptable (for example a conflict > with other modules). This is where overrides would come in. The amavis module would have classes that inherit and override the MTA classes. But how to do so in a manner such that the MTA in use can be anything and that the amavis module doesn't need to know about the MTA specifics is a challenge and one that isn't quite clear how best to handle. Right now, in our case, we just craft everything specific to the MTA that we use (postfix) so we would not be able to swap out to sendmail by simply changing the package name in one manifest: we would need to make additional changes b/c config files are different, etc. -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
