Hey Henrik! There was a long discussion in Slack about this that didn't get carried into the ticket description. Re: “makes the result of lookup depend on order of evaluation”: You're right, and we are aware of that concern. We had a long Slack discussion about best practices, user awareness of this kind of issue, what appropriate guard-rails should be, or how aggressively we should protect against users doing this. There is nowhere else in Hiera that programmatically protects against the use of local-scope variables in the hierarchy as far as I know, so the suggested default option topscope_variables_only=true and associated error message actually provides more protection for the proposed getvar backend than we have anywhere else. We considered permitting only $facts or $trusted to be used here by default as well. The current suggestion of any top-scope variable without opting in to what Puppet tells you is a bad idea is because it's usually a safe bet that top-scope variables are set before classes are evaluated, and therefore reasonably permissible. Re: “Don’t however try to make `paths` be anything other than file paths” That sounds like a valuable implementation note to be aware of. For now, updated the description to use "uris". Re: “you can write your own backend function […] that is super simple to do in a custom backend function” This is where we started, actually, and was one of the options considered and discussed in the Slack thread. The main counter-point is disagreement that for users writing a customer back-end function is that simple. It's simple to write a function, but more complicated to know that you can write a backend, choose an appropriate backend type, and put it together. Not that hard, but definitely a barrier. The original impetus for this ticket was implementing an integration with ServiceNow through the trusted_external_command feature. If we want to do this, and only do it ourselves, for ServiceNow, then we just write a servicenow bakcend. But if we want users to be able to do this more generally, including for in-house use of trusted_external_command, we should provide a generalized backend for this in Puppet. |