On 15/09/17 19:18, 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.
What do you mean by "to work the way it used to" - you have never been
able to bind to anything but module namespaced keys in modules.
Earlier everything was in top scope.
There is absolutely nothing stopping you from using the old practice of
having the global layer refer to data files inside of modules. This is a
choice you make - it is bad in general but works if you are in control
of where a module gets used (you are creating a dependency that the
module must be present). I.e. a conscious decision made at the env or
global level.
You could also write a simple aggregation function that takes a list of
modules as input (from hiera.yaml) - this is a list of modules that for
example contribute "users". You function when being asked to supply the
key for a user "fred_flintstone", it looks up in each module and you are
then in charge of dealing with that merge).
There are many other options here - I am not sure I understand the
concerns about URIs HTTP/DB queries well enough to advice in more detail.
Hope you got something to work with from the above.
Best,
- henrik
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/
<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
<mailto: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
<https://groups.google.com/d/msgid/puppet-users/80759536-03b7-4f9b-80ea-39e13dcf0ef8%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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/oph357%24k1m%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.
