Open Stack

On Thu, Mar 24, 2016 at 01:39:01AM -0400, Rabi Mishra wrote:
> > On Wed, Mar 23, 2016 at 05:25:57PM +0300, Sergey Kraynev wrote:
> > >    Hello,
> > >    It looks similar on issue, which was discussed here [1]
> > >    I suppose, that the root cause is incorrect using get_attr for your
> > >    case.
> > >    Probably you got "list"  instead of "string".
> > >    F.e. if I do something similar:
> > >    outputs:
> > >      rg_1:
> > >        value: {get_attr: [rg_a, rg_a_public_ip]}
> > >      rg_2:
> > >        value: {get_attr: [rg_a, rg_a_public_ip, 0]}
> > >                      
> > >      rg_3:
> > >        value: {get_attr: [rg_a]}
> > >      rg_4:
> > >        value: {get_attr: [rg_a, resource.0.rg_a_public_ip]}
> > >    where rg_a is also resource group which uses custom template as
> > >    resource.
> > >    the custom template has output value rg_a_public_ip.
> > >    The output for it looks like [2]
> > >    So as you can see, that in first case (like it is used in your example),
> > >    get_attr returns list with one element.
> > >    rg_2 is also wrong, because it takes first symbol from sting with IP
> > >    address.
> > 
> > Shouldn't rg_2 and rg_4 be equivalent?
> 
> They are the same for template version 2013-05-23. However, they behave differently
> from the next  version(2014-10-16) onward and return a list of characters. I think 
> this is due to the fact that `get_attr` function mapping is changed from 2014-10-16.

Ok, I guess it's way too late to fix it, but it still sounds like a
backwards incompatible regression to me.

Steve