RFE Proposal: lookup_options in the manifest

[Alan Evans]

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.

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?

Would it make more sense as a Data Type or a function() w/ some invisible data type that APL uses?

Does this belong in puppet proper?  Stdlib? (Could it go in stdlib?)

Please discuss.

-Alan

[jcbollinger]

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

[Henrik Lindberg]

On 2019-12-12 02:59, 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?

Exactly, and that is why the options should be in the data because that
is the place where data structure was defined!

As an example you may not want to have merging at all and override
a value with a complete hash. You don't want to change a manifest to do
that.

> 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.

> > *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().
>
> |
> classfroboz(
> 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.
>
> |
> classbozfro(
>   $some_param =Lookup(Array[String],'unique',undef),

>   $another_param =lookup_options(Hash,'deep',{knockout_prefix =>'-'}),

> ){# Do Useful Stuff}
> |
>

A default value expression is evaluated if there were no data given in
the manifest and if no data was found when doing a lookup. So, cannot
use the default value expression to try to influence the lookup as that
would break the contract of when those are evaluated.

> Do you think lookup_options seem out of place in the hiera data?

No they are at the right place.

> Would it make more sense as a Data Type or a function() w/ some
> invisible data type that APL uses?

You would then need to invent new syntax.

> Does this belong in puppet proper?  Stdlib? (Could it go in stdlib?)
>

It cannot go into stdlib it would need to be an integral part of the
language.


You either use APL and stick the options into hiera as needed, or you
do not bind to any APL looked up keys and use an explicit lookup in the
default value expression. If you do that then you can specify the
options in your manifest.

I recommend using APL.

- henrik

> Please discuss.
>
> -Alan
>
> --
> 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...@googlegroups.com
> <mailto:puppet-users...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/50a3ed15-92e1-42f4-99e5-833dd3d12710%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/50a3ed15-92e1-42f4-99e5-833dd3d12710%40googlegroups.com?utm_medium=email&utm_source=footer>.


--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/