I'll resurrect this old thread to give an update. We landed a function in stdlib to do some of what I discussed in my last post, by inspecting module metadata directly.
The function: https://github.com/puppetlabs/puppetlabs-stdlib#load_module_metadata A blog post I wrote about some possible uses: http://scienceofficersblog.blogspot.com/2015/08/inspecting-puppet-module-metadata.html -- Spencer Krum n...@spencerkrum.com On Mon, Feb 23, 2015, at 03:32 PM, Spencer Krum wrote: > The use case I think for having multiple modules of the same name > available is quite limited. I don't think anyone would claim best > practice if they had two apache modules in their modulepath. > > I also think there is another component which is versioning. Right now > there is no system for a profile module to know what version of e.g. > rabbitmq is installed. This means it just assumes one and fails if the > rabbitmq class takes different parameters now. One terrible workaround > for this is for classes to accept a 'rabbitmq_module_version' parameter > and then switch on it inside the class. This workaround is actually > used. > > So I think as long as we're discussing how to make module owner > detectable, requireable, whatever, that we should involve versioning as > well, because bumping minor or major versions of utility modules like > postgres, mysql, rabbitmq happens a lot. > > One case that actually happens where there is a want for two different > modules by the same name, is when an organization is migrating. An org > that is moving from example42-apache to puppetlabs-apache isn't gonna > want to have a flag day where everything is broken. They don't really > want to play move hosts one by one out of an environment into a testing > environment then into a 'done' environment. This is where being able to > have two modules of the same name could be really useful. > > Erik proposed allowing modules to specify an interface, then other > modules could implement that interface. I don't think that is a likely > outcome. I think when we have two modules that both manage 'apache' the > only reason one hasn't totally taken over the other is because they have > different underlying ideas about how to manage apache. I.e. what the > inputs are and what the scope of the outputs are. > > We on the openstack infrastructure team have even gone so far as to fork > an old version of the apache module to openstackinfra-httpd. This is > 0.0.4 of the pl-apache module and takes wildly different inputs. There > are three reasons for the fork. One, this module takes a template, fills > it out, and dumps it in a vhost. Clean and simple. The way we think it > should be. Two, now that we have forked we can update the codebase, > clean it up, and fix bugs. Three, with the module now living as 'httpd' > in our module path, we, or others consuming our infra, can use a modern > version of the apache module for whatever they need. > > > As a final thought. One way to deal with this problem is to socialize > the requirement of a new metadata file (yay) called something like > manifests/properties.pp. This file would have all the data in > metadata.json. But since it is readable by puppet we could end up with > code that looks like this in our profiles: > > class profile () { > > case $::apache::properties::author { > 'puppetlabs': { > // do some apache stuff the puppetlabs way > } > 'example42': { > // do some apache stuff the example42 way > } > 'default': { fail("please stop writing your own apache module") } > } > > } > > And the technique for handling multiple versions of the same module is > basically exactly the same. The cool part of this is that it requires no > code changes to puppet core. The bad part is we'd have to socialize it > and thats really hard. > > > -- > Spencer Krum > n...@spencerkrum.com > > On Fri, Feb 20, 2015, at 04:34 PM, Henrik Lindberg wrote: > > On 2015-20-02 20:51, Wil Cooley wrote: > > > In some ways, this is a lot like environments, but unlike environments, > > > which are unique at the node-level, these allow the use of multiple > > > module-sets and are scoping for entities at the manifest-level. As I > > > understand environments, they can (and probably usually should) be > > > relatively isolated from each other; the purpose of namespaced > > > module-sets is to allow addressing without isolation. Maybe this is what > > > Henrik's last message in this thread is getting at when he says: > > > > > > I have claimed on many occasions that an environment is just like a > > > module (with higher privileges / precedence). The set of available > > > modules should be more of a repository kind of thing that the loader > > > resolves modules from. > > > > I meant that an environment can be seen as a module. Instead of having a > > modulepath, it should list all the modules that it requires (those > > modules in turn can require other modules). When a module is needed it > > should be resolved against a repository of modules. Such a repository > > could be implemented many ways; one being that it is just the modules > > now on the modulepath. > > > > The main difference is that the resolution from name to actual module is > > now free from implementation concerns. > > > > Currently the dependencies that are expressed are between the containers > > of logic (the module depends on another specific module with a specific > > implementations e.g. puppetlabs/stdlib). This is simple but not very > > flexible. It would be far better if the requirements were established > > based on what is actually required from that module - say that it needs > > a function 'foo'. Then that could be declared and any module that > > happens to make that function available is a potential replacement. The > > same is applicable to other elements of the puppet language, classes, > > defines, types, etc. > > > > Such a scheme requires something to select the modules that are actually > > wanted out of all potential modules. This could be the role of the > > environment module - it would have dependencies on the modules that > > should be used. It is not limited to that however since any module can > > act as a configuration (by having explicit dependencies on other > > modules) - such modules does not have to contain anything but the > > dependencies. They become reusable parts of configuration thus making it > > easier to set up many different environments. > > > > While this increases flexibility it also adds complexity. It is also > > not the complete solution to all the things discussed in this thread, > > but I believe it could be the foundation for most of them. > > > > - henrik > > > > -- > > > > Visit my Blog "Puppet on the Edge" > > http://puppet-on-the-edge.blogspot.se/ > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to puppet-dev+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/puppet-dev/mc8jqc%24hus%241%40ger.gmane.org. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/1424730766.2492445.231441093.2BCFFDD7%40webmail.messagingengine.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/1439593257.4184712.356657409.76A141BB%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
