Jira (BOLT-116) Consider the contents and format of a possible bolt.conf

[Nathan Shobe (JIRA)]

Title: Message Title

Nathan Shobe commented on BOLT-116   Re: Consider the contents and format of a possible bolt.conf @Hendrik Lindberk My main issue with that approach is you're then assuming everyone has access to your entire hiera stack, and/or always runs these bolt tasks from the puppet server. Both of those are likely not going to be the case/possible in larger or more secure organizations. These config items are workstation side, not target host side, so you're essentially going to hand over the right for any workstation to make arbitrary queries to hiera? There's a really good reason hiera was done the way it was and also now expanded with data in modules. Honestly, I think hiera 5 is the most important change to puppet in the last 2-3 years, as it allows distributing trust within an organization without having to design your own hiera backend. Also, hiera-eyaml gem wouldn't need to become a dependency, just something a user can add if needed. There would still be a lot of benefit from the structured hash yaml approach for the config, but going as far as adding hiera as a dependency seems a bit heavy handed. Add Comment   This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- 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. For more options, visit https://groups.google.com/d/optout.