On Wednesday, December 11, 2019 at 7:59:47 PM UTC-6, Alan Evans wrote:
>
> I love Automatic Parameter Lookup (APL) and hiera in general. But one
> thing I have found awkward is that `lookup_options` are found in the hiera
> data. In general the idea is to separate data from code right? Lookup
> options do not feel like data to me, but more like something I would find
> in the code the same way in the code I can type class parameters.
>
I don't really see the supposed parallel between expressing (only) lookup
options in code and explicitly specifying parameter data themselves in code.
We have had discussions in this area before, and I don't think there's much
controversy here. The data type and significance of each parameter is a
matter of code, but the way in which parameters' associated data are
expressed is a matter of the data. Lookup options are an aspect of the
latter -- they belong in or associated with the data, not in manifest code.
Of course, you can express whatever lookup options you like to the lookup()
function for retrieving non-parameter data, but I consider even that to
have a bit of code smell.
> *Proposal*
>
> Create a data type (or function perhaps that returns a data type) that
> tells the APL code HOW to do the lookup. The lookup key is just the
> class/name of the current param and the rest of the arguments could behave
> like lookup().
>
> class froboz(
> Array[String] $my_param = LookupOptions('unique'),
> Hash $options = LookupOptions('deep', knockout_prefix=>'-',
> default_value=>undef),
> ) {# Do Useful Stuff}
>
> Or maybe just *Lookup* with a capital *L* or perhaps a function
> *lookup_options()* that returns some internal class/data type that need
> not be visible to the puppet user.
>
> class bozfro(
> $some_param = Lookup(Array[String], 'unique', undef),
> $another_param = lookup_options(Hash, 'deep', {knockout_prefix => '-'}),
> ) {# Do Useful Stuff}
>
> Do you think lookup_options seem out of place in the hiera data?
>
No, not really. I could see them going into separate files alongside the
data to eliminate the need for a reserved key, but under no circumstances
do I see it being appropriate to tie them to classes.
> Would it make more sense as a Data Type or a function() w/ some invisible
> data type that APL uses?
>
No. The lookup options speak to what the data are. They are
characteristic of the data, not of the class (if any) that uses them.
Consider also: what about data other than those associated with class
parameters? What about class parameter data accessed directly via the
lookup() function (maybe from a different class)? What about data
providers other than Hiera?
> Does this belong in puppet proper? Stdlib? (Could it go in stdlib?
>
None of the above. Lookup options expressed in Hiera data constitute
metadata about the data. They speak to the meaning of data expressed
across multiple files, and it is appropriate for them to be associated
closely with the data. There is room to talk about the propriety of
expressing these metadata alongside the data themselves in the very same
files, but they do not in any case belong in manifests.
To put it another way, it is the author of the data who should be in
control of the lookup options that are in effect for each key. Choosing
those appropriately is one of their tools for supplying
situationally-correct data to the catalog builder. Putting those decisions
instead into the hands of class authors would be a huge step *backward* in
the area of code / data separation.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/97630826-15cb-4e0e-a704-e0275098a0ca%40googlegroups.com.
