This thread is music for my hears... I'm sorry to have missed the list in the last days, and I take the occasion to reopen this thread it in order to avoid that also this one fades forgotten as various other threads, in the past, about modules standards, naming conventions, metadata and interoperability. I'm glad that there's new drive, directlty from RL, on this topic and I'm definitively willing to contribute in some way.
So, even if this might not be the right place and time, I'd like to throw in some points. I've just recently started to extend multiOS support in my modules and I'm still trying to figure out the best way to handle that but one thing is sure: a way to routinely test modules behavious on different OS and different Puppet versions is necessary. I wonder (or, better, ask to James) if Puppet continuos integration ( http://reductivelabs.com/trac/puppet/wiki/Development/PuppetContinuousIntegration ) relates only to Puppet building and its tests or can (will) be somehow applied on Puppet runs on a set of Puppet Modules. Besides this, I think that big isses in interoperability about different sets of modules raise in the use of custom types, different approaches to the same problem, and different ways to handle cross- modules functions, such has monitoring, backup, firewall management and so on, that generally work well only inside the same set of modules. I like, and have played a bit with, the idea of using "wrappers" with (erm... ) standard naming conventions to manage common activities. Something like: A "wrapper" define called "Config" to manage files' inline modifications using different methods ( something like: http://www.example42.com/browser/common/manifests/defines/config.pp ) A wrapper module/define called "Monitor" to manage monitoring of nodes (and services/ports/file systems...) using different monitoring tools (according to custom needs) so that in your (standard) module you just define what you want to Monitor with a standard naming convention, using then the Monitor method you prefer ( some embrional attempts here: http://www.example42.com/browser/monitor/manifests/init.pp ) Similar wrappers can be used for Backup or Firewall and so on. I Love the idea to have, for example, an Apache module where is wrtitten: I want to Backup /var/www/html (or whatever) AND make the Firewall open input port 80 without caring what backup system I use and how I manage my firewalls (that is done and customized in the backup and firewall modules...) Dunno if I made the point. Last but not least, I would like to have a shared modules environment where I can choose the module I want, for the same application, among alternatives. I'm costantly looking at how others do theirs modules and I always learn a lot from them (DavidS, Camptocamp, Vulcane's PuppetManaged to name a few), still most of the times, when I wanted to import and use modules made by others, I found myself rewriting them in order to follow my own way of thinking, my knowledge (or lack of) and style to approach the same problem. This is probably the same for eveybody, so I don't think there should be just ONE approach in a module for an application, but a base structure, and different alternatives/defines/subclasses to choose from. But hey, I know, I'm putting too much inside this pot, big results are achieved in small steps, so Michael and RL, drive the path, do as you've said ("no need to design up-front on the list") and tell us what we can do. Alessandro -- 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.
