Henrik Cheers for the quick response. I haven't tried this scenario on 4.x, and I doubt I will for quite a while...
OK, so to elaborate on the namespace thing, and possibly try and explain what I'm trying to achieve... I've got module_a, which uses DIM, and defines a key of 'module_a::key_a'. Module_a also contains a template, which has a simple 'scope.function_hiera(['module_a::key_a'])'. If I evaluate that template in a resource within module_a, then it should look up the value without issue? What happens if module_b uses the template defined by module_a? Is that now namespaced to 'module_b'? Ergo Puppet would never be able to get the key value from module_a DIM? I think that explains the issue I'm seeing a bit better... Cheers Gavin On Monday, 16 May 2016 12:48:36 UTC+1, Henrik Lindberg wrote: > > On 16/05/16 13:00, Gavin Williams wrote: > > Morning all... > > > > I've hit a bit of an issue with our usage of Data-In-Modules (DIM) > > provided by ripienaar/module_data with Puppet 3.7.x and was wondering > > what the best option might be... > > > > TL;DR: How can I change the DIM Hiera lookup scope to use the correct > > module? > > > > Currently, we have the following module architecture: > > > > 1. Profile module service class, which wraps: > > 2. Specific service module, which wraps: > > 3. A common 'service-framework' module. > > > > The 'service module' uses DIM to provide sane defaults for lots of param > > values, which can then be over-ridden in the profiles class. > > It also provides a config template snippet that's specific to that > > service, which then gets evaluated in the 'service-framework' module. > > > > The issue I'm hitting is that the scope used for the DIM Hiera lookups > > is preventing Hiera from resolving the specific service modules data > > files... > > > > In order to illustrate this better, I've done a simple example available > > here [1]. > > > > The README shows an example failure when attempting to run the RSpec > > unit tests within the 'profile_module', which correlates with the error > > I'm getting with trying to actually use this same functionality... > > It also shows a working test from within the 'calling_module', which is > > effectively the service specific module... > > > > I did manage to come up with a slightly ugly hack[2] to the module_data > > hiera backend, which makes the tests pass... > > However my understanding is that the same logic has been adopted by > > Puppet core in the 4.x series, which obviously means we'll hit exactly > > the same issue if/when we come to upgrade to 4.x... > > > > The logic from R.I's DIM module is not in puppet 4.x. It is a quite > different implementation. If you are having problems with the 4.x > implementation please log an issue. > > There was too much to look at in your example + R.I's implementation and > I could not quite figure out if what you patched fixes a bug or if it > changed something conceptually. > > The 4.x implementation allows a module to bind to keys in its own > namespace (and not in others). When looking something up, if the key is > in a module namespace, it will be looked up there if not overridden by > something with higher precedence. There is never an issue with "lookup > from" as the 4.x implementation looks at keys/namespaces being looked up. > > > So yeh, any pointers on how best to 'resolve' this issue? > > > > Unless you are trying to bind to non module namespace keys from within > a module, the 4.x implementation should work for you. > > - 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 Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/139342a3-2745-46f4-a0fd-abe494b085c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
