I had a similar but "not quite the same" challenge. Basically I just added
a custom ruby function to let you parse the data you're looking for. So in
addition to lookup (), I now have things like consul_servicenames() which
dumps all services presented by a host in an array format (handy for if $a
in $b scenarios). It basically means building a few custom parsers in ruby
into your backend module to cover common lookup "Styles" that match your CM
layout. By storing them all in the backend module they are available
essentially globally and simply called differently.
On Friday, September 15, 2017 at 10:18:03 AM UTC-7, John Baird wrote:
>
> Right, and that's exactly my concern with NOT being able to do exactly
> that.
>
> Scenarios
> 1. I wish to lookup a URI that is to be configured for a module. The
> module name here is obviously not important, but let's call it "mymodule".
> In the manifest, I wish to lookup ssh keys being served up by Consul (as I
> am currently doing). I would like to simply lookup('username') where
> 'username' is the user whose public key I would like to authorize onto my
> system.
> 1a. This means, lookup('username') will only work for top scope.
> 1b. Option 1, change scope of lookup. my lookup now needs to be
> "sshkeys::username", but now my URI lookup path is going to be
> "/path/to/some/uri/sshkeys::username" in consul. Surely there's a better
> way than having a bunch of k/v pairs with namespaced keys in them ?
> 1c. Option 2, everything is top scope when I care about doing URI lookups.
> 1d. This would be fine except if now I want to have a list of all active
> users on the system as a simple list in another module. Now whichever URI
> path is first will return the data, and not necessarily the appropriate
> data for the lookup.
>
> I understand that it's not supposed to work the way it used to, but come
> one, this functionality almost seems common place. Using an HTTP or file
> backend is CRITICAL in many ecosystems.
>
> I suppose I can write some regsub on the lookup to parse out the namespace
> prior to appending it to the URI, but that seems insanely hackish...
> Personally, if I do a lookup from within a module, it should automatically
> append the current namespace to it for lookup, then this issue goes away.
>
> On Friday, September 15, 2017 at 10:54:19 AM UTC-5, Henrik Lindberg wrote:
>>
>> On 15/09/17 16:46, John Baird wrote:
>> > I just realized, while doing some other hiera work with a custom HTTP
>> > backend, that this won't work. It's the same problem I have with the
>> > way scoping works for the HTTP backend. If I don't specify the
>> lookup()
>> > key in the manifest with a scope, then puppet ONLY uses GLOBAL and
>> > ENVIRONMENT scope and ignores module scope. This seems undesired. In
>> > that manner, I would have to have my filenames (in the case of file
>> > backend) or URIs (as is the case with HTTP backend) contain module
>> > scoping in the lookup, so my filename would become
>> > lookup('somemodule::somefile.txt") which would THEN have to actually
>> > exist in that lookup...
>> >
>>
>> yes, modules cannot bind to names in the global (top) name space.
>> If they could they would have the potential to step on each other and it
>> will become impossible to resolve a lookup without visiting every module
>> on the modulepath for every lookup.
>>
>> hiera is not ignoring module scope - it is simply illegal to try to bind
>> to anything that is not in the module's namespace.
>>
>> > I would expect Puppet to use module scope when a lookup is performed
>> > within the module if scope is not specified for this lookup.
>>
>> It simply does not work that way. There are no "relative keys".
>>
>> - 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/464701d5-ab5d-436f-b79b-b152a4e0ba5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
