Jira (BOLT-836) Support Hiera lookup() in plans outside of apply blocks
Title: Message Title Yasmin Rajabi updated an issue Puppet Task Runner / BOLT-836 Support Hiera lookup() in plans outside of apply blocks Change By: Yasmin Rajabi Labels: ghm Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.275693.1536882656000.58718.1565910960573%40Atlassian.JIRA.
Jira (BOLT-836) Support Hiera lookup() in plans outside of apply blocks
Title: Message Title Henrik Lindberg commented on BOLT-836 Re: Support Hiera lookup() in plans outside of apply blocks 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. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google
Jira (BOLT-836) Support Hiera lookup() in plans outside of apply blocks
Title: Message Title Alex Dreyer updated an issue Puppet Task Runner / BOLT-836 Support Hiera lookup() in plans outside of apply blocks Change By: Alex Dreyer h2. Feature RequestIt would be handy to support the hiera lookup() function within a plan.h2. Open QuestionWhat goes into the hierarchy for a plan? Without facter how are those values set? h2. Usecasesh4. Lookup different values to use the same plan in different environments or contextsAs 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.h4. Use hiera to lookup task parameters for different targetsAs 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.h2. 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.
Jira (BOLT-836) Support Hiera lookup() in plans outside of apply blocks
Title: Message Title Alex Dreyer updated an issue Puppet Task Runner / BOLT-836 Support Hiera lookup() in plans outside of apply blocks Change By: Alex Dreyer Summary: Support Hiera lookup() in plans outside of apply blocks Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.275693.1536882656000.8823.1558022280357%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
