Henrik,
I really appreciate your patience here, but I feel like there is something
obvious that I am either not grasping or isn't spelled out in the
documentation.
Let's say I make a function called `lookup_file` which will do the
File.Read in whatever manner I need. I can call that from my manifests to
lookup the file, but how, then do I lookup the context from hiera? It's
the combination of these two things that seems abstract to me and is
preventing me from moving forward. I understand how to do both
individually, but I'm not sure how to retrieve the hiera context for the
path from within this "other" function....
I can see that any file_backend function I create chomps the key on the
first "." as we previously discussed, which means that I need to call a
function BEFORE that in order to call my file_backend from within my
file_lookup function, for instance.
How do I get the options and context to be used from the function my
manifest will be using? Let's assume in my manifest:
content => lookup_file('/tmp/somefile.txt')
does this work in my backend?
Puppet::Functions.create_function(:file_backend) do
dispatch :file_backend do
param 'String', :key
param 'Hash', :options
param 'Puppet::LookupContext', :context
end
def file_backend(key, options, context)
searchroot = options['path']
filename = "#{searchroot}/#{filename}"
# If file is found, return contents of file
# If file is not found, context.not_found()
end
def lookup_file(key)
options = :options
context = :context
file_backend(key, :options, :context)
end
end
I think that's the part I am struggling with... hiera knows about the
context and options, but my manifest knows (or should know) the proper key
to look up. How do I combine them so I retrieve the contents of the file?
On Sat, Sep 2, 2017 at 3:29 AM Henrik Lindberg <[email protected]>
wrote:
> 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 [email protected]
> > <mailto:[email protected]>.
> > 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 a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/TNDd6f8K6H8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> 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.
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CACSjNA4Uk7hHP5zbODY4YT9BTboEVuu5WqKSJeAR83sO7ScD6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
