| I was thinking that you bind the value facts.selinux.enabled to docker::selinux_enabled key. Then, you make that value special using lookup_options - in a way defining the syntax & semantics of what is there. One way (as I suggested) is to simply take the value and give it to a function (that defines the meaning of the value). Then, you could (if you wanted to) put a string of Puppet code as the value of the lookup, and say the function is puppet_eval if you wanted to - i.e. completely open ended extendable by functions. So, specifically for aliases I imagine the function would be something like `strict_alias` and it would be called with the looked up value, and the function would then use the context it gets to perform a lookup using the value it got as the key. You can do really powerful things with a general purpose "delegate". Another option here (not using lookup_options) would be to add the delegate support as an interpolation function (even though (as stated earlier) have a dislike for "non interpolation features expressed as an interpolation"). This would require some more expressiveness in how you can invoke interpolation functions, for example giving multiple arguments to it, support for different kinds of literal data, etc. etc. - and that starts to snowball... It could be something like:
some::key: "%{`puppet: ...puppetcode here `}" |
some::key: "%{`myfunc: ...whatever myfunc understands`}"
|
But I have not thought much about that idea as opposed to having the `puppet` or `myfunc` part be in lookup_options and then just putting whatever the argument should be into the value. One thing is that you could probably combine so that the key looks up a hash (maybe even with merge) and then get that as input to your function. ... Maybe it is not so much a `delegate` as a `post_process` since it would be acting on the looked up result... Anyhow, there are probably dragons to watch out for, and meanwhile, I have to objection against adding a strict_ailas interpolation function. (I am just brainstorming about what we could possibly do for the future to allow anyone to innovate in this area without requiring further additions to puppet/hiera itself and without completely changing the hiera data syntax. One more thought... the lookup_option could be a kind of delegation, that if turned on it expects the lookup result to be a hash, and it expects a key in this hash to be the function to call with that hash as argument - then you would see something like this in data (using a puppet_eval as an example):
some::key: |
delegate: puppet_eval |
code: "getvar('facts.foo.bar')"
|
With that it would be clear what it is doing (as opposed to having to also look at the lookup_options) although you need to understand that "delegate" (or "hiera_delegate" perhaps) is a special hiera thing and not just "data". </rambling> |
