It would be handy to support the hiera lookup() function within a plan.
What goes into the hierarchy for a plan? Without facter how are those values set?
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.
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.
- 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.