(This description has been updated to reflect the decisions made in comments up to comment-147302)
With the new agnostic data in modules (and environments) introduced in
PUP-1640 we really need a way to use the data provided in other ways than just binding class parameters.
We currently have a function called lookup that looks up in Puppet Binder, and then in hiera. This functionality is not particularly valuable to users as they are most likely not going to use the Binder for anything directly looked up from Puppet Language code.
Instead, we should repurpose lookup to be the equivalent of the hiera function, and add options to it to do the equivalent of hiera_array and hiera_hash.
The hiera_include function is not really needed, but could also be considered.
(hiera_include is the same as a lookup followed by an iteration that does include - e.g:
The lookup arguments are already quite rich, and adding support for merge lookup of array and hash could be added as additional options rather than separate functions, although there are additional options when using the hash merge (specifically, passing option on to 'deeper' merge) that may warrant separating them.
This has consequences on the data providers:
- they must get the same options (or else a layered backend such as hiera cannot do the merge, and will not expose its internals to the caller, so caller cannot do merge).
- the recursion locking must be done without passing an argument since a backend may call code that in turn cannot pass the recursion lock on.
A solution for the recursion locking is to use a Puppet.context and set a look_up_key_lock hash that the implementations can use to check the lock.
|add acceptance tests for lookup()||Closed||Unassigned|