Open Stack

On 06/11/14 20:44, Steven Hardy wrote:
> 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.


Crazy thought: why not just implement conditionals? We had a proto-spec 
for them started at one point...

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>