Uploaded image for project: 'Hiera'
  1. Hiera
  2. HI-471

Allow backends to perform Qualified Key Lookup

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: HI 3.1.0
    • Component/s: None
    • Labels:
      None
    • Template:
    • Story Points:
      1
    • Sprint:
      Language 2015-10-28, Language 2015-11-11, Language 2015-12-02
    • Release Notes:
      New Feature
    • Release Notes Summary:
      Hide
      This new feature is for implementors of hiera backends.

      Hiera backends can now opt in to a new feature in the backend API that allows the backend to be responsible for producing values from subkeys. This is beneficial for backends that would otherwise have to produce a very large hash (e.g. from a database or ldap) only to be reduced to a single looked up value and the returned data. Now the backend can instead opt in to do the required slicing.
      Show
      This new feature is for implementors of hiera backends. Hiera backends can now opt in to a new feature in the backend API that allows the backend to be responsible for producing values from subkeys. This is beneficial for backends that would otherwise have to produce a very large hash (e.g. from a database or ldap) only to be reduced to a single looked up value and the returned data. Now the backend can instead opt in to do the required slicing.

      Description

      Since HI-14, Hiera can lookup leaf elements from structured data. This was implemented by splitting the lookup key into period-separated values and calling into the backends for the the first token only. Hiera then pulls out the requested value from the data returned from the backend.

      For certain backends with deeply structured data, the first token may contain a substantial amount of data that is non-trivial to return. Imagine, for example, a LDAP backend that can return data about users and groups on the system:

      hiera users.user123.shell

      would have to return the entire users hash, which could contain thousands of superfluous records when we only want a string. Passing the entire key to the backend and letting it intelligently handle what data to retrieve could be a huge optimization.

      The difficulty in implementation is how the backend can tell Hiera that it supports Qualified Key Lookups so that Hiera doesn't try to do it itself.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                ezell Matthew Ezell
              • Votes:
                2 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Zendesk Support