On Sat, Feb 13, 2010 at 7:42 PM, Al @ Lab42 <lab42...@gmail.com> wrote: > 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.
We were talking a bit about how to do this for a more integration based test farm. Seems like it is not wise to just use puppet to check puppet there, and this could get complex. > > 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. Yeah, I understand it. Everyone's infrastructure is managed slightly differently, so trying to make something for everyone is difficult :) It will be a challenge, no doubt! I very much like the idea of trying to abstract out the "what you are doing" (monitoring) with the "how you are monitoring" (ex: nagios). I need to dig closely through example42 and the others more in the near future to gather up a list of the ideas we want to incorporate. > > 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. Hmm.... I understand the thinking. I think what I want to build here is a "mostly acceptable to 80% of everyone" way to do it out of the box, as a 'best practices' type of repo (actually this is looking more and more like a set of repos) with a way for people to also host/fork there own repos once we start to add tooling around this. The central 'main' repo will be curated and reviewed, so all the modules follow the same kinds of ideas and work well together .... though it's up to everyone to kind of do a trial by fire at arriving at that. These other sets of repos should be easily attachable with the common tools though. TBD? I'd prefer we don't get too idiomatic if possible so the examples can also be instructive. Here's an example -- One thing that came up in training was an idiom for copying a file to temp, checking it with visudo, and copying it to the intended location if the check passed. For instance, in that case, it makes sense to write a "ValidatedFile" type and put it in the common module repo. In other words, we are not only creating a shared resource of modules, but we're also trying to make something that serves as self-documenting tips-and-examples at the same time, and something that is easy to contribute to. FWIW, we're mostly calling the common module "Forge" at the moment, so I'll probably start referring to it as that. It is shorter :) > > 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. Yeah, I apologize for not having immediate cycles to pound away on this -- but look for something to start moving in March or so. I think most likely we'll just set up a new account on github for these and each module can be a repo, and we do some (very very minimal) ruby tooling to make this be usable at first until we see what we need. > > 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. > > -- 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.
