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 [email protected] 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 > [email protected] > > 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 [email protected]. > > 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 [email protected]. > 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 [email protected]. 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.
