| Some thoughts about implementation... One thing to consider here is that switching "perpective" (bolt controller, each node) using a single hiera instance will lead to its cache being evicted on each switch. This would potentially be quite bad for performance if many such switches are required as a bolt run progresses. Imagine looping over a set of nodes and in each iteration some plan specific, and some node specific value needs to be obtained. From a UX perspective everything could be hidden unless it should be possible to lookup node specific values in a plan. For that, it must be possible to use a different perspective. This could be another function for example (lookup_for_node()), or a method on a node/target. When designing the "perpectives", a big question is if it should be possible to override a node perspective in the plan perspective. If not, it may be possible to have one hiera/lookup-context per node in memory if performance is bad using switching of the set of values used to determine the paths in the hierarchy. Maybe it is possible to make hiera switch between named (i.e. "perspective specific") caches in an effective way. It seems like a design with one hierarchy for the plan perspective, and one for all node specific perspectives would be best, and if override of node perspective is needed in plan perspective, then that can be done manually in the plan's logic. |
