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.
