Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-5395

Set resolution_type when using data bindings by using lookup_options

    XMLWordPrintable

Details

    • New Feature
    • Status: Closed
    • Normal
    • Resolution: Fixed
    • None
    • PUP 4.3.0
    • None
    • 1
    • Language 2015-10-28, Language 2015-11-11, Language 2015-12-02
    • New Feature
    • Hide
      This adds a new feature to automatic data binding and the lookup function that allows the lookup options to be defined in the data by binding keys in a hash bound to the key {{lookup_options}}. This makes it possible to get deep merge behavior for select class parameters.
      Show
      This adds a new feature to automatic data binding and the lookup function that allows the lookup options to be defined in the data by binding keys in a hash bound to the key {{lookup_options}}. This makes it possible to get deep merge behavior for select class parameters.

    Description

      Because it's the responsibility of the caller to set `resolution_type` in hiera, and there is no explicit caller when using data bindings, there's no way to tell hiera to use the array (append) or hash (merge) resolutions. This is a pretty bad flaw as it prevents sophisticated lookups like deep merges (or, well, any merges at all) when using the fancy data bindings.

      UPDATE


      This new feature allows the default lookup options to be individually controlled per parameter by binding a hash to the key lookup_options, where each key in that hash is the fully qualified name of a parameter. The value should be a hash that defines the default lookup options for that key.

      The lookup_options are looked up with hash-merge, making it possible to compose the content of the lookup_options hash using multiple sources (data files in a hierarchy, across, global hiera, environment data provider and module providers. With data in modules in effect, this means that a module can specify the behavior of its own parameters (e.g. 'merge' for some of its keys). At higher priority layers no action needs to be taken except if there is a desire to change the default specification.

      The options bound per key under lookup_options are also used as the defaults for the lookup function.
      Note that the defaults does not apply to the hiera_xxx family of functions, they continue to work as before (as these functions themselves represents specifying some of the options (e.g. hiera_array is for arrays, and hiera_hash is for hashes). It is recommended to always use the lookup function instead of the hiera_xxx functions since they a) work with "data in modules", and b) makes use of the default lookup options.

      The only thing that can be specified (currently) is the merge option (as specified by the lookup function). This means that the behavior can be one of the strings: first, unique, hash, merge, deep, or a hash with its strategy key set to one of those strings, and where further options are knock_out_prefix, sort_merged_arrays, unpack_arrays, and merge_hash_arrays - (See the lookup function for details).

      The lookup_options will never be found when used as the key in a regular lookup. It's not considered to be data in the normal sense but rather meta_data describing the data. Also, there is never a need to prefix the lookup_options key with a module name since the module name will be determined by looking at the key that initiated the lookup.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              redmine.exporter redmine.exporter
              Eric Thompson Eric Thompson
              Votes:
              17 Vote for this issue
              Watchers:
              37 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Zendesk Support