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.
