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
