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.

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/ 
>
>

-- 
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/9f084cd5-73b7-4b17-9c81-8a386af77dc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to