Uploaded image for project: 'Puppet Task Runner'
  1. Puppet Task Runner
  2. BOLT-836

Support Hiera lookup() in plans outside of apply blocks

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Normal
    • Resolution: Won't Do
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Template:
    • QA Risk Assessment:
      Needs Assessment

      Description

      Feature Request

      It would be handy to support the hiera lookup() function within a plan.

      Open Question

      What goes into the hierarchy for a plan? Without facter how are those values set? 

      Usecases

      Lookup different values to use the same plan in different environments or contexts

      As a plan author i need to store data about how to execute the plan that may be environment or deployment specific. These settings would be looked up from the "perspective" of the bolt controller node. Example: may need different API keys, credentials, etc to use for API calls. Example 2: may be deploying in a different manner based on a setting in a config that is easy to switch.

      Use hiera to lookup task parameters for different targets

      As a plan author i need to perform actions differently depending on certain facts and/or attributes of a node. These facts may be gather by the `facts` task. From these facts/attributes i then need to lookup() data to determine how the action should be run.  These facts would be looked up from the "perspective" of specific targets. Example: I'm deploying a software pacakge against a variety of hosts, some may be 32-bit some 64-bit. I need to deploy different versions of software to the 32-bit systems. I would run a 'facts' task to determine architecture, then choose which software package to copy and install. The data hierarchy would be used to uniquely specify which software package to utilize.

      Learning from spike

      • currently just exposing hiera allows backends to work without interpolation as long as all interpolation is based on $facts and $trusted. The fact that those are set during plan execution feels wrong and may be a bug.
      • We probably need the ability for users to specify a separate hiearchy for the plan level so we don't limit interpolation options.
      • There is value in exposing backends so that hiera-eyaml can be used but this problem may be solved by supporting eyaml in inventory.

      h1 Questions for commentors

      • What levels of heirarchy would you use at the plan level?
      • Would there be any fact like interpolations in the hierarchy? What values would be used.
      • Do you expect values from plan level data to be automatically set anywhere with data bindings like classes in manifests.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              nmaludy Nick Maludy
            • Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Zendesk Support