Open Stack

On Wed, Nov 05, 2014 at 02:46:43PM +0000, Lee, Alexis wrote:
>    I'm considering adding a function which takes a list and returns the first
> 
>    non-null, non-empty value in that list.
> 
>    So you could do EG:
> 
>        some_thing:
> 
>            config:
> 
>                ControlVIP:
> 
>                    first_nonnull:
> 
>                    - {get_param: ControlVIP}
> 
>                    - {get_attr: [ControlVirtualIP, fixed_ips, 0,
>    ip_address]}]}
> 
> 
>    I'm open to other names, EG "some", "or", "fallback_list" etc.
> 
>    Steve Hardy suggested building this into get_attr or Fn::Select. My
>    feeling is that those each do one job well right now, I'm happy to
>    take a steer though.

Ah, from our IRC discussion I was thinking you wanted primarily list
filtering of get_attr output, thus thinking an optional argument would make
more sense than a new function.

I see now that you're actually looking for something of a poor-mans
conditional, so you choose either the ControlVIP parameter, or the
ControlVirtualIP attribute, for which your proposal is probably cleaner -
my concern is just that we avoid a proliferation of different list
select/filter functions, when we could just have one.

To clarify I wasn't suggesting we add anything into Fn::Select, but
possibly implementing a native alternative which does what Fn::Select does
and includes optional list filtering, e.g something flexible which can do
more than just select a non-null value, e.g something like:

    list_select:
        - {get_param: ControlVIP}
        - {get_attr: [ControlVirtualIP, fixed_ips, 0, ip_address]}]}
        - 0
        - non_null

This would take any number of list arguments, join them, then take an
index value, and an optional filter value.  Maybe we could even make the
"0" optional and default to zero, provided there's a non-overlapping range
of input allowed for the index and filter arguments.

Don't have a very strong opinion on the name, but FWIW I prefer
first_nonnull over coalesce, just because the latter is really clear
if you know the mysql function, and really not if you don't :)

Happy to hear other ideas, but I think it's good that we discuss this
before committing to an interface (either here or in a spec review).

Steve