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

Reroute hiera_xxx functions to the new lookup logic

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: PUP 4.9.0
    • Component/s: None
    • Labels:
      None
    • Template:
    • Acceptance Criteria:
      Hide

      That the hiera_xxx functions continues to work as they do now until user opts in to hiera 5, and debug logging contains output from the lookup explainer. When opting in, lookup is across all layers, and "override-paths" feature raises an error.

      Show
      That the hiera_xxx functions continues to work as they do now until user opts in to hiera 5, and debug logging contains output from the lookup explainer. When opting in, lookup is across all layers, and "override-paths" feature raises an error.
    • Team:
      Puppet Developer Experience
    • Story Points:
      3
    • Sprint:
      PDE 2016-12-14, PDE 2017-01-11, PDE 2017-01-25
    • Release Notes:
      New Feature
    • Release Notes Summary:
      Calls to the hiera functions now takes environment and module data configurations into account if having opted in with a hiera.yaml version 5 in an environment.
    • QA Risk Assessment:
      Automate
    • QA Risk Assessment Reason:
      simple acceptance to ensure it still works until removal

      Description

      The hiera_xxx functions are currently hardwired directly to Hiera 3 and the global data layer. They should instead be rerouted to use the new lookup logic as follows:

      • If the environment has no hiera.yaml the calls to hiera_xxx continues to work as before.
      • If the environment has a hiera.yaml this is taken as a signal that the user has opted in to the new behavior. The hiera_xxx functions now operate across all layers. At the same time, if there is logic that makes use of the hiera "override paths" functionality an error is raised as that feature is incompatible with hiera 5.
      • If the global hiera.yaml is version 5 the same rules apply as if there is an env's hiera.yaml.

      The motivation for this is:

      • This replaces the earlier idea that users must reroute their hiera_xxx with overrides in site.pp as that just makes users that opt-in having to opt-in twice.
      • Users must be able to lazily migrate environments and modules
      • The set of users that have modules that use "override-paths" in explicit hiera calls in modules they do not have control over is expected to be very low
      • Out of the box behavior is unchanged except if users have opted in to hiera.yaml v4 in their environments. Since that feature is experimental we have the right to change the behavior. At the same time, the set of users having opted in to hiera.yaml v4 and also using hiera calls with "override-paths" is an even smaller group of users (probably none).

      The upside for users is that migration to hiera.yaml v5 in environments as well as global can be performed without also having to update all modules w.r.t hiera_xxx calls at the same time.

      The lookup logic must be enhanced in two ways to accommodate the new requirements. It must be possible to:

      • do a lookup that involves only the global layer.
      • add new overrides (hierarchy paths) directly in a call (for the case where the hiera.yaml is v3 and there is no heira.yaml in the env).

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                thomas.hallgren Thomas Hallgren
                QA Contact:
                Eric Thompson
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Zendesk Support