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/80759536-03b7-4f9b-80ea-39e13dcf0ef8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
