| It was a very conscious design decision to not let a module define anything outside of its namespace by just having the module on the modulepath.
In order to configure anything else this must be designed into modules that want such cooperation, or by someone that adds this as a feature to mix into the hierarchy. There is already a default_hierarchy separate from the regular hierarchy - only used if regular hierarchy does not produce a value. Cooperation between modules can be done by referencing data files in another module (or environment) - then there is no restriction on namespace, data files are simply data and any restrictions would depend on where those files are referenced; for example if module A uses a path that references a file in module B, then the data must have keys that are namespaced for A. Cooperation can also be done by adding a lookup_key function - it would transpose keys from one namespace to another. For example, if module A has a::x and you want to provide that value from module B, then module B could bind to say b::for::a::x, and the function translates the key "a::x" to "b::for::a::x" (or something like that). If this is wanted as some kind of default this lookup key function is placed in the default hierarchy. When doing this, I can imagine that the function would take options to define which keys it would transpose, and to what/which modules. If desired, that function could take a list of modules (defines the precedence) and it could perform merging of the result). Would those be workable solutions for the described case? If so, no changes would be required to hiera to support this. |
