On 01/09/17 01:32, John Baird wrote:
Henrik,
I think the disconnect is coming from the fact that the documentation
only goes so far. In that, I mean, what should my lookup be from my
manifest?
Should my manifest be:
$somefile = lookup('/etc/example.txt')
and then specify the file_backend in my hiera.yaml?
Or should my manifest be:
$somefile = file_backend('/etc/example.txt')
and then specify the file_backed in my hiera.yaml?
If I do the former, is specifying the ":key" just implied?
If I do the latter, I end up in a situation where the file_backend
function is looking for more arguments than just the simple filename.
I feel like that's what's not really clear, since the YAML and JSON
backends simply append the key to the options path without ever
specifying the actual key existing in the backend. So it's a little
confusing how I should actually be interacting with the custom backend.
The big difference between the YAML and JSON backends is that they load
files with keys in them. In your case the key is the "name" of the file!
The JSON and YAML backends are of the data_hash kind. They are called
once and must produce a hash of all the keys in the file pointed to by
the path the backend is given. You do not want that since it would mean
that you would have to slurp in all of the data files on the initial
call. That could be a problem if you have lots of large files and they
are not all needed for every compilation.
Instead you need to deliver the value for a key per lookup of that key.
The simple implementation takes the key appends it to the root path,
reads that file and returns it as the value. If the file does not exist
it should instead call $context.not_found().
- henrik
On Monday, August 28, 2017 at 2:03:09 AM UTC-5, Henrik Lindberg wrote:
On 28/08/17 00:45, John Baird wrote:
> The backend function receives a path in the options hash -
that path is
> guaranteed to exist - all non existing paths are simply
skipped by
> hiera
> (see the linked docs how it works). Thus, you do not need to
use any of
> the find file, etc. You can use relative paths in the
hiera.yaml config
> and hiera will figure it out (see the docs).
>
>
> Henrik,
>
> I believe I fully understand the context here, however, is the
"options"
> hash not fully referenced within the "hiera.yaml" ? Basically,
how do I
> access the lookup of the key itself from within a puppet manifest
as an
> appendage of the options['path']. I really believe that is the
piece I
> am just not able to connect. Can you help me understand how to
do this?
> Thanks!
>
Not quite sure exactly where there is a piece of information
missing, so
pardon if I explain too much here.
When hiera 5 processes a lookup it will visit each entry in the
hiera.yaml. Such an entry may use one out of several ways to specify a
set of file paths to check for existence (path, paths, glob). If the
path corresponds to something existing, a call is made to the function
associated with that entry. It receives an options hash where path is
set to the path that was found to be existing. This is repeated for all
the existing paths found in that entry.
A user may have given additional options in the options hash.
If the mode of the lookup is "priority" (first found) the search for a
value stops when a function produces a value for the key being searched
for. If the search is a kind of "merge" then the search continues until
all values for the key have been found.
You can use the fact that the hiera framework performs the existence
check. If you do a glob to match all of the files your function will be
called with each - then simply check if the leaf file name matches the
key being looked up. Call "not_found" for all others, and read and
return the content for the one that matches.
By doing that you get a small advantage in that you will not be
incurring checks for lots of file existence for all of the keys that
are
irrelevant and never will have a matching file.
Does this help with what you were wondering about?
- 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/9f084cd5-73b7-4b17-9c81-8a386af77dc4%40googlegroups.com
<https://groups.google.com/d/msgid/puppet-users/9f084cd5-73b7-4b17-9c81-8a386af77dc4%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/oodq2v%241su%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.
