Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-24 Thread Zane Bitter

On 24/03/16 04:29, Steven Hardy wrote:

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.


It is backwards incompatible, but it's not a regression. This is the 
exact reason why we have versioned templates.


It's an intentional feature, done by the book with a template version 
bump, which you +2'd at the time :)


https://bugs.launchpad.net/heat/+bug/1341048
https://git.openstack.org/cgit/openstack/heat/commit/?id=eca6faa83e13a43546f7533b52e0fd3071fd97d4
https://git.openstack.org/cgit/openstack/heat/commit/?id=b4903673cd24efd631df79d33cfe4bd07a4243d6

- ZB

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-24 Thread Zane Bitter

On 24/03/16 01:39, 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.


2013-05-23 -  
https://github.com/openstack/heat/blob/master/heat/engine/hot/template.py#L70
2014-10-16 -  
https://github.com/openstack/heat/blob/master/heat/engine/hot/template.py#L291


Correct. I think that's probably the source of confusion.


This makes me wonder why would a template author do something like
{get_attr: [rg_a, rg_a_public_ip, 0]} when he can easily do


This is why: https://bugs.launchpad.net/heat/+bug/1341048
You can do things with 2014-10-16 that aren't possible with 2013-05-23.


{get_attr: [rg_a, resource.0.rg_a_public_ip]} or {get_attr: [rg_a, resource.0, 
rg_a_public_ip]}
for specific resource atrributes.


Yep, these are the only correct ways of doing this in 2014-10-16 and up, 
and the first is the only efficient way of doing it in 2013-05-23 (note: 
the second way works only in 2014-10-16 and up).



I understand that {get_attr: [rg_a, rg_a_public_ip]} cane be useful when we 
just want to use
the list of attributes.


Indeed.

- ZB


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-24 Thread Steven Hardy
On Wed, Mar 23, 2016 at 05:05:17PM -0400, Zane Bitter wrote:
> On 23/03/16 13:35, Steven Hardy 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]}
> 
> There's actually another option here too that I personally prefer:
> 
>   rg_5:
> 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?
> 
> Nope, rg_2 returns:
> 
>   [[0], [0], ...]
> 
> If this makes no sense, imagine that rg_a_public_ip is actually a map rather
> than a string. If you want to pick one key out of the map on each member and
> return the list of all of them, then you just have to add the key as the
> next argument to get_attr. This makes get_attr on a resource group work
> somewhat differently to other resources, but it's the only sensible way to
> express this in a template:

Ah, yeah I was thinking of the returned list containing simple string IP's
vs a map, this makes more sense now - thanks!

It has to be said, this RG attributes interface is really confusing, even
for all of us, so we probably need to improve the docs for users.

I did create this example template a long time ago, but it seems based on
this discussion that it's in need of an update and more comments (probably
in addition to improving the resource docs as well).

https://github.com/openstack/heat-templates/blob/master/hot/resource_group/resource_group.yaml

Cheers,

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-24 Thread Steven Hardy
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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-24 Thread Sergey Kraynev
Rabi,

Good point. I suppose, that the root cause of it is gap in our documentation.
Unfortunately I can not find any clear description what's the
differences or how it should work (especially with examples) in our
documentation. [1]

May be we need to improve it by adding more examples ?

[1] 
http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#get-attr

On 24 March 2016 at 08:39, 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.
>
>
> 2013-05-23 -  
> https://github.com/openstack/heat/blob/master/heat/engine/hot/template.py#L70
> 2014-10-16 -  
> https://github.com/openstack/heat/blob/master/heat/engine/hot/template.py#L291
>
> This makes me wonder why would a template author do something like
> {get_attr: [rg_a, rg_a_public_ip, 0]} when he can easily do
> {get_attr: [rg_a, resource.0.rg_a_public_ip]} or {get_attr: [rg_a, 
> resource.0, rg_a_public_ip]}
> for specific resource atrributes.
>
> I understand that {get_attr: [rg_a, rg_a_public_ip]} cane be useful when we 
> just want to use
> the list of attributes.
>
>
>>
>> {get_attr: [rg_a, rg_a_public_ip]} should return a list of all
>> rg_a_public_ip attributes (one list item for each resource in the group),
>> then the 0 should select the first item from that list?
>>
>> If it's returning the first character of the first element, that sounds
>> like a bug to me?
>>
>> Steve
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards,
Sergey.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-23 Thread Rabi Mishra
> 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.


2013-05-23 -  
https://github.com/openstack/heat/blob/master/heat/engine/hot/template.py#L70
2014-10-16 -  
https://github.com/openstack/heat/blob/master/heat/engine/hot/template.py#L291

This makes me wonder why would a template author do something like 
{get_attr: [rg_a, rg_a_public_ip, 0]} when he can easily do 
{get_attr: [rg_a, resource.0.rg_a_public_ip]} or {get_attr: [rg_a, resource.0, 
rg_a_public_ip]}
for specific resource atrributes.

I understand that {get_attr: [rg_a, rg_a_public_ip]} cane be useful when we 
just want to use
the list of attributes.


> 
> {get_attr: [rg_a, rg_a_public_ip]} should return a list of all
> rg_a_public_ip attributes (one list item for each resource in the group),
> then the 0 should select the first item from that list?
> 
> If it's returning the first character of the first element, that sounds
> like a bug to me?
> 
> Steve
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-23 Thread Zane Bitter

On 23/03/16 13:35, Steven Hardy 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]}


There's actually another option here too that I personally prefer:

  rg_5:
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?


Nope, rg_2 returns:

  [[0], [0], ...]

If this makes no sense, imagine that rg_a_public_ip is actually a map 
rather than a string. If you want to pick one key out of the map on each 
member and return the list of all of them, then you just have to add the 
key as the next argument to get_attr. This makes get_attr on a resource 
group work somewhat differently to other resources, but it's the only 
sensible way to express this in a template:


https://bugs.launchpad.net/heat/+bug/1341048

Whereas rg_4 and rg_5 just return:

  


{get_attr: [rg_a, rg_a_public_ip]} should return a list of all
rg_a_public_ip attributes (one list item for each resource in the group),
then the 0 should select the first item from that list?

If it's returning the first character of the first element, that sounds
like a bug to me?

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-23 Thread Sergey Kraynev
Steven,

Honestly I thought about it, but I am not sure, which behavior was
before for both. I don't mind if we create such bug and investigate
the root cause (unfortunately I had not time to do it yet).
The my main point was to provide workable way for mentioned issue.

p.s. there is corresponding bug was created
https://bugs.launchpad.net/heat/+bug/1561157

On 23 March 2016 at 20:35, Steven Hardy  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?
>
> {get_attr: [rg_a, rg_a_public_ip]} should return a list of all
> rg_a_public_ip attributes (one list item for each resource in the group),
> then the 0 should select the first item from that list?
>
> If it's returning the first character of the first element, that sounds
> like a bug to me?
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards,
Sergey.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-23 Thread Steven Hardy
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?

{get_attr: [rg_a, rg_a_public_ip]} should return a list of all
rg_a_public_ip attributes (one list item for each resource in the group),
then the 0 should select the first item from that list?

If it's returning the first character of the first element, that sounds
like a bug to me?

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-23 Thread Sergey Kraynev
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.
rg_3 - does not work at all  (because it's custom template resource)
the right way is rg_4, which returns IP address string .

[1]
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg77526.html

[2] http://paste.openstack.org/show/491587/

On 23 March 2016 at 14:15, Ma, Wen-Tao (Mike, HP Servers-PSC-BJ) <
wentao...@hpe.com> wrote:

>
>
> Hi Sergey,
>
> Here is our tracked logs. we can notice that  kube_master resource can
> return the output value "kube_master_ip": "10.101.58.117"  , but It
> can’t  get the kube_master_ip value in kube_minions of
> *kubecluster-fedora-ironic.yaml.*
>
> I found about this heat template composition configuration at
> https://ask.openstack.org/en/question/56988/get-outputs-from-nested-stack/
> . It is same with us.
>
> *#heat resource-list --nested-depth 5 cf0e4e53-e703-4d78-b2e3-90c7081c39fe*
>
>
> +---+--++-+-+-+
>
> | resource_name | physical_resource_id |
> resource_type
> | resource_status | updated_time|
> stack_name  |
>
>
> +---+--++-+-+-+
>
> | kube_master   | 65d68ca7-6629-4203-b40b-359f53be8c79 |
> OS::Heat::ResourceGroup
> | CREATE_COMPLETE | 2016-03-23T18:12:44 |
> k8sbay-rzqvufyi24q5 |
>
> | kube_minions  | 9a3d3d0c-104e-4887-9961-f4d6b6dc392f |
> OS::Heat::ResourceGroup
> | CREATE_FAILED   | 2016-03-23T18:12:44 |
> k8sbay-rzqvufyi24q5 |
>
>
> +---+--++-+-+-+
>
>
>
> *#heat resource-show 65d68ca7-6629-4203-b40b-359f53be8c79 0*
>
>
> ++--+
>
> | Property   |
> Value
>   
>  |
>
>
> ++--+
>
> | attributes |
> {
> |
>
> ||   "kube_master_external_ip":
> "10.101.58.117",
> |
>
> ||   "kube_master_ip": "10.101.58.117"
>   
>  |
>
> ||
> }
>
> |
>
> …
>
> | resource_status|
> CREATE_COMPLETE
> |
>
>
> ++--+
>
>
>
>
>
> *Here is the three k8s heat yaml file.*
>
> *kubecluster-fedora-ironic.yaml*
>
> kube_master:
>
> type: OS::Heat::ResourceGroup
>
> properties:
>
>   count: 1
>
>   resource_def:
>
> type: kubemaster-fedora-ironic.yaml
>
> properties:
>
>   ssh_key_name: {get_param: ssh_key_name}
>
>   server_image: {get_param: server_image}
>
>   …
>
>
>
> kube_minions:
>
> type: OS::Heat::ResourceGroup
>
> depends_on:
>
>   - kube_master
>
> properties:
>
>   count: {get_param: number_of_minions}
>
>   removal_policies: [{resource_list: {get_param: minions_to_remove}}]
>
>   resource_def:
>
> type: 

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-14 Thread Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
Hi Sergey,

Thanks a lot. 
What I am using is Liberty release of Heat in a devstack environment.

I'll provide my trace log later.

Regards,
Gary

-Original Message-
From: Sergey Kraynev [mailto:skray...@mirantis.com] 
Sent: Friday, March 11, 2016 10:23 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

Hi Gary,

I have tried your template and it works for me correctly. Note, that I used 
private network (because my servers have not any public IP in template).

So your issue looks like a strange bug, because I can not reproduce it.
Could you share traceback if your error and also provide information about Heat 
version. Please create new bug with all this data and ping us to review it.

On 11 March 2016 at 08:25, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
<li-gong.d...@hpe.com> wrote:
> Hi Sergey,
>
> Thanks for your reply.
>
> Thanks for your pointing out that "depends_on" is not needed when we have 
> already used "get_attr".

So as Zane pointed, when we use get_attr it's expected, that we start create 
rg_b, when rg_a will be finally completed/created , because all information (in 
your case it's attributes) will be available after creation of rg_a.

In heat we have two types of dependencies explicit and implicit. So implicit 
dependencies will be created with using some Heat intrinsic functions. 
Depends_on add explicit dependency. All these dependencies work in the same 
way, depended resource will be created, when all his dependencies be resolved 
(created).

>
>>you create in rg_a some Server and probably it goes to active state 
>>before ip address becomes available for get_attr. It is necessary to 
>>check, but if it's try to add wait condition for this resource, then 
>>you will get created rg_a with fully available resources and I suppose 
>>IP will be available
>
> Do you mean that with "depends_on" functionalities, Heat will launch another 
> resource group(in my case, "rg_b") as soon as the server in "rg_a" becomes 
> "active" state?
> Actually, in my real program code, there is  a wait condition, but it is 
> located in the server template, not Resource group(in my case, it is 
> "b.yaml), which is like:
> --
> rg_a_wc_notify:
> type: OS::Heat::SoftwareConfig
> properties:
>   group: ungrouped
>   config:
> str_replace:
>   template: |
> #!/bin/bash -v
> wc_notify --data-binary '{"status": "SUCCESS"}'
>   params:
> wc_notify: {get_attr: [master_wait_handle, curl_cli]}
> --
> Is it the wait condition which you mentioned in " but if it's try to add wait 
> condition for this resource"? or you want this wait condition to be added to 
> "a.yaml"(the template declaring resource group)?
>
> And as per my observation, only after Heat receives the signal of "SUCCESS", 
> then it try to begin launch "rg_b"(my another server in another resource 
> group).
>
> I am wondering whether there is a chance that, the "IP" information is 
> available but Heat doesn't try to get it until the creation of the 2 resource 
> groups(rg_a and rg_b) is completed?



>
> Regards,
> Gary
>
> -Original Message-
> From: Sergey Kraynev [mailto:skray...@mirantis.com]
> Sent: Wednesday, March 09, 2016 6:42 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat 
> template
>
> Hi Gary,
>
>
> First of all you don't need to use "depends_on", because using "get_attr" 
> already create implicit dependency from rg_a.
> About getting Null instead of real Ip address:
> It sounds like a bug, but IMO, it's expected behavior, because I suppose it 
> happens due to:
>  - you create in rg_a some Server and probably it goes to active state before 
> ip address becomes available for get_attr. It is necessary to check, but if 
> it's try to add wait condition for this resource, then you will get created 
> rg_a with fully available resources and I suppose IP will be available.
>
> On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
> <li-gong.d...@hpe.com> wrote:
>> Hi,
>>
>>
>>
>> I have 3 Heat templates using ResourceGroup. There are 2 resource 
>> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires 
>> the IP address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip: 
>> {get_attr:
>> [rg_a, rg_a_public_ip]}” to get the 

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-11 Thread Zane Bitter

On 11/03/16 00:48, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) wrote:

Hi Zane,

Thanks for your reply.
I guess you mean that IP address of rg_a should be available AS SOON AS/AFTER  
the server of rg_a becomes CREATE_COMPLETE? As Sergey pointed out, there is a 
chance that IP address might be available when the server of rg_a becomes 
CREATE_COMPLETE. Actually, IMHO, it depends on when a server becomes ACTIVE or 
CREATE_COMPLETE. It will becomes ACTIVE or CREATE_COMPLETE when the OS is boot 
up but initiation services(such as network interface starting up) has not been 
done or when both OS itself and initialization jobs such as daemon service up 
and network interface up, IP assigned.


Servers don't assign IP addresses to themselves. Neutron assigns one 
when it creates a (virtual) port for the server to attach to. We should 
be able to see what this IP address is long before the server has 
booted, and anything exposed as an attribute of a resource MUST be 
available by the time the resource becomes CREATE_COMPLETE otherwise 
Heat's whole data flow model is broken.



Regards,
Gary

-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com]
Sent: Thursday, March 10, 2016 5:40 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

On 09/03/16 05:42, Sergey Kraynev wrote:

Hi Gary,


First of all you don't need to use "depends_on", because using
"get_attr" already create implicit dependency from rg_a.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's expected behavior, because I
suppose it happens due to:
   - you create in rg_a some Server and probably it goes to active
state before ip address becomes available for get_attr. It is
necessary to check, but if it's try to add wait condition for this
resource, then you will get created rg_a with fully available
resources and I suppose IP will be available.


I would have expected the IP address to be available before the server becomes 
CREATE_COMPLETE. If it isn't then I'd consider that a bug too - as you pointed 
out, people are relying on the dependency created by get_attr to ensure that 
they can actually get the attribute.

cheers,
Zane.


On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
<li-gong.d...@hpe.com> wrote:

Hi,



I have 3 Heat templates using ResourceGroup. There are 2 resource
groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires
the IP address of rg_a as the paremeter of rg_b. I use "rg_a_public_ip: 
{get_attr:
[rg_a, rg_a_public_ip]}" to get the IP address of rg_a both in the
section of rg_b parameters (rg_b/properties/resource_def/properties)
and the section of outputs.

As per my observation,  rg_a_public_ip shows "null" in the parameter
section of rg_b. while rg_a_public_ip shows the correct IP address in
the outputs section of the yaml file.



My questions are:

1)  Does this behavior is expected as designed or this is a bug?

2)  What is the alternative solution for the above case(user want to get
the run-time information of the instance when creating the second
resource
group)  if this behavior is expected?



--- a.yaml ---

resources:

rg_a:

type: OS::Heat::ResourceGroup

properties:

count: 1

resource_def:

type: b.yaml

properties:

 ...



rg_b:

type: OS::Heat::ResourceGroup

depends_on:

  -rg_a

properties:

  count: 2

  resource_def:

  type: c.yaml

  properties:

  rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
  the value is "null"

  ...



outputs:

 rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
-  the value is correct.

--



--b.yaml  

...

resources:

  rg_a:

type: OS::Nova::Server

properties:

   ...

outputs:

   rg_a_public_ip:

   value: {get_attr: [rg_a, networks, public, 0]}

--



-- c.yaml 

parameters:

rg_a_public_ip:

   type: string

   description: IP of rg_a

...

resources:

rg_b:

  type: OS::Nova::Server

  properties:

   ...

  outputs:

   ...

---



Regards,

Gary




_
_ OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev








__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://li

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-11 Thread Sergey Kraynev
Hi Gary,

I have tried your template and it works for me correctly. Note, that I
used private network (because my servers have not any public IP in
template).

So your issue looks like a strange bug, because I can not reproduce it.
Could you share traceback if your error and also provide information
about Heat version. Please create new bug with all this data and ping
us to review it.

On 11 March 2016 at 08:25, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
<li-gong.d...@hpe.com> wrote:
> Hi Sergey,
>
> Thanks for your reply.
>
> Thanks for your pointing out that "depends_on" is not needed when we have 
> already used "get_attr".

So as Zane pointed, when we use get_attr it's expected, that we start
create rg_b, when rg_a will be finally completed/created , because all
information (in your case it's attributes) will be available after
creation of rg_a.

In heat we have two types of dependencies explicit and implicit. So
implicit dependencies will be created with using some Heat intrinsic
functions. Depends_on add explicit dependency. All these dependencies
work in the same way, depended resource will be created, when all his
dependencies be resolved (created).

>
>>you create in rg_a some Server and probably it goes to active state before ip 
>>address becomes available for get_attr. It is necessary to check, but if it's 
>>try to add wait condition for this resource, then you will get created rg_a 
>>with fully available resources and I suppose IP will be available
>
> Do you mean that with "depends_on" functionalities, Heat will launch another 
> resource group(in my case, "rg_b") as soon as the server in "rg_a" becomes 
> "active" state?
> Actually, in my real program code, there is  a wait condition, but it is 
> located in the server template, not Resource group(in my case, it is 
> "b.yaml), which is like:
> --
> rg_a_wc_notify:
> type: OS::Heat::SoftwareConfig
> properties:
>   group: ungrouped
>   config:
> str_replace:
>   template: |
> #!/bin/bash -v
> wc_notify --data-binary '{"status": "SUCCESS"}'
>   params:
> wc_notify: {get_attr: [master_wait_handle, curl_cli]}
> --
> Is it the wait condition which you mentioned in " but if it's try to add wait 
> condition for this resource"? or you want this wait condition to be added to 
> "a.yaml"(the template declaring resource group)?
>
> And as per my observation, only after Heat receives the signal of "SUCCESS", 
> then it try to begin launch "rg_b"(my another server in another resource 
> group).
>
> I am wondering whether there is a chance that, the "IP" information is 
> available but Heat doesn't try to get it until the creation of the 2 resource 
> groups(rg_a and rg_b) is completed?



>
> Regards,
> Gary
>
> -Original Message-
> From: Sergey Kraynev [mailto:skray...@mirantis.com]
> Sent: Wednesday, March 09, 2016 6:42 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template
>
> Hi Gary,
>
>
> First of all you don't need to use "depends_on", because using "get_attr" 
> already create implicit dependency from rg_a.
> About getting Null instead of real Ip address:
> It sounds like a bug, but IMO, it's expected behavior, because I suppose it 
> happens due to:
>  - you create in rg_a some Server and probably it goes to active state before 
> ip address becomes available for get_attr. It is necessary to check, but if 
> it's try to add wait condition for this resource, then you will get created 
> rg_a with fully available resources and I suppose IP will be available.
>
> On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
> <li-gong.d...@hpe.com> wrote:
>> Hi,
>>
>>
>>
>> I have 3 Heat templates using ResourceGroup. There are 2 resource
>> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires the
>> IP address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip: 
>> {get_attr:
>> [rg_a, rg_a_public_ip]}” to get the IP address of rg_a both in the
>> section of rg_b parameters (rg_b/properties/resource_def/properties)
>> and the section of outputs.
>>
>> As per my observation,  rg_a_public_ip shows “null” in the parameter
>> section of rg_b. while rg_a_public_ip shows the correct IP address in
>> the outputs section of the yaml file.
>>
>>
>>
>> My questions are:
>>
>> 1)  Does this behavior is expected as des

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-10 Thread Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
Hi Jay,

Thanks for your reply.

> Is this still an issue when you remove the resource group and create the 
> resource directly? The count of 1 might just be for testing purposes, but if 
> that's the end goal you should be able to drop the group entirely.

Unfortunately, the count of 1 is just for testing purpose and my end goal is 
that the count should be inputed as paramaters.

Regards,
Gary

-Original Message-
From: Jay Dobies [mailto:jason.dob...@redhat.com] 
Sent: Thursday, March 10, 2016 5:55 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template



On 3/9/16 4:39 PM, Zane Bitter wrote:
> On 09/03/16 05:42, Sergey Kraynev wrote:
>> Hi Gary,
>>
>>
>> First of all you don't need to use "depends_on", because using 
>> "get_attr" already create implicit dependency from rg_a.
>> About getting Null instead of real Ip address:
>> It sounds like a bug, but IMO, it's expected behavior, because I 
>> suppose it happens due to:
>>   - you create in rg_a some Server and probably it goes to active 
>> state before ip address becomes available for get_attr. It is 
>> necessary to check, but if it's try to add wait condition for this 
>> resource, then you will get created rg_a with fully available 
>> resources and I suppose IP will be available.
>
> I would have expected the IP address to be available before the server 
> becomes CREATE_COMPLETE. If it isn't then I'd consider that a bug too 
> - as you pointed out, people are relying on the dependency created by 
> get_attr to ensure that they can actually get the attribute.
>
> cheers,
> Zane.
>
>> On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
>> <li-gong.d...@hpe.com> wrote:
>>> Hi,
>>>
>>>
>>>
>>> I have 3 Heat templates using ResourceGroup. There are 2 resource 
>>> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires 
>>> the IP address of rg_a as the paremeter of rg_b. I use 
>>> "rg_a_public_ip:
>>> {get_attr:
>>> [rg_a, rg_a_public_ip]}" to get the IP address of rg_a both in the 
>>> section of rg_b parameters (rg_b/properties/resource_def/properties) 
>>> and the section of outputs.
>>>
>>> As per my observation,  rg_a_public_ip shows "null" in the parameter 
>>> section of rg_b. while rg_a_public_ip shows the correct IP address 
>>> in the outputs section of the yaml file.
>>>
>>>
>>>
>>> My questions are:
>>>
>>> 1)  Does this behavior is expected as designed or this is a bug?
>>>
>>> 2)  What is the alternative solution for the above case(user want
>>> to get
>>> the run-time information of the instance when creating the second 
>>> resource
>>> group)  if this behavior is expected?
>>>
>>>
>>>
>>> --- a.yaml ---
>>>
>>> resources:
>>>
>>> rg_a:
>>>
>>>type: OS::Heat::ResourceGroup
>>>
>>>properties:
>>>
>>>count: 1

Is this still an issue when you remove the resource group and create the 
resource directly? The count of 1 might just be for testing purposes, but if 
that's the end goal you should be able to drop the group entirely.


>>>resource_def:
>>>
>>>type: b.yaml
>>>
>>>properties:
>>>
>>> ...
>>>
>>>
>>>
>>> rg_b:
>>>
>>> type: OS::Heat::ResourceGroup
>>>
>>> depends_on:
>>>
>>>  -rg_a
>>>
>>> properties:
>>>
>>>  count: 2
>>>
>>>  resource_def:
>>>
>>>  type: c.yaml
>>>
>>>  properties:
>>>
>>>  rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>>>   the value is "null"
>>>
>>>  ...
>>>
>>>
>>>
>>> outputs:
>>>
>>> rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>>> -  the value is correct.
>>>
>>> --
>>>
>>>
>>>
>>> --b.yaml  
>>>
>>> ...
>>>
>>> resources:
>>>
>>>  rg_a:
>>>
>>> type: OS::Nova::Server
>>>
>>> properties:
>>>
>>&

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-10 Thread Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
Hi Zane,

Thanks for your reply.
I guess you mean that IP address of rg_a should be available AS SOON AS/AFTER  
the server of rg_a becomes CREATE_COMPLETE? As Sergey pointed out, there is a 
chance that IP address might be available when the server of rg_a becomes 
CREATE_COMPLETE. Actually, IMHO, it depends on when a server becomes ACTIVE or 
CREATE_COMPLETE. It will becomes ACTIVE or CREATE_COMPLETE when the OS is boot 
up but initiation services(such as network interface starting up) has not been 
done or when both OS itself and initialization jobs such as daemon service up 
and network interface up, IP assigned.

Regards,
Gary

-Original Message-
From: Zane Bitter [mailto:zbit...@redhat.com] 
Sent: Thursday, March 10, 2016 5:40 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

On 09/03/16 05:42, Sergey Kraynev wrote:
> Hi Gary,
>
>
> First of all you don't need to use "depends_on", because using 
> "get_attr" already create implicit dependency from rg_a.
> About getting Null instead of real Ip address:
> It sounds like a bug, but IMO, it's expected behavior, because I 
> suppose it happens due to:
>   - you create in rg_a some Server and probably it goes to active 
> state before ip address becomes available for get_attr. It is 
> necessary to check, but if it's try to add wait condition for this 
> resource, then you will get created rg_a with fully available 
> resources and I suppose IP will be available.

I would have expected the IP address to be available before the server becomes 
CREATE_COMPLETE. If it isn't then I'd consider that a bug too - as you pointed 
out, people are relying on the dependency created by get_attr to ensure that 
they can actually get the attribute.

cheers,
Zane.

> On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
> <li-gong.d...@hpe.com> wrote:
>> Hi,
>>
>>
>>
>> I have 3 Heat templates using ResourceGroup. There are 2 resource 
>> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires 
>> the IP address of rg_a as the paremeter of rg_b. I use "rg_a_public_ip: 
>> {get_attr:
>> [rg_a, rg_a_public_ip]}" to get the IP address of rg_a both in the 
>> section of rg_b parameters (rg_b/properties/resource_def/properties) 
>> and the section of outputs.
>>
>> As per my observation,  rg_a_public_ip shows "null" in the parameter 
>> section of rg_b. while rg_a_public_ip shows the correct IP address in 
>> the outputs section of the yaml file.
>>
>>
>>
>> My questions are:
>>
>> 1)  Does this behavior is expected as designed or this is a bug?
>>
>> 2)  What is the alternative solution for the above case(user want to get
>> the run-time information of the instance when creating the second 
>> resource
>> group)  if this behavior is expected?
>>
>>
>>
>> --- a.yaml ---
>>
>> resources:
>>
>> rg_a:
>>
>>type: OS::Heat::ResourceGroup
>>
>>properties:
>>
>>count: 1
>>
>>resource_def:
>>
>>type: b.yaml
>>
>>properties:
>>
>> ...
>>
>>
>>
>> rg_b:
>>
>> type: OS::Heat::ResourceGroup
>>
>> depends_on:
>>
>>  -rg_a
>>
>> properties:
>>
>>  count: 2
>>
>>  resource_def:
>>
>>  type: c.yaml
>>
>>  properties:
>>
>>  rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>>   the value is "null"
>>
>>  ...
>>
>>
>>
>> outputs:
>>
>> rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>> -  the value is correct.
>>
>> --
>>
>>
>>
>> --b.yaml  
>>
>> ...
>>
>> resources:
>>
>>  rg_a:
>>
>> type: OS::Nova::Server
>>
>> properties:
>>
>>   ...
>>
>> outputs:
>>
>>   rg_a_public_ip:
>>
>>   value: {get_attr: [rg_a, networks, public, 0]}
>>
>> --
>>
>>
>>
>> -- c.yaml 
>>
>> parameters:
>>
>> rg_a_public_ip:
>>
>>   type: string
>>
>>   description: IP of rg_a
>>
>> ...
>>
>> resources:
>>
>> rg_b:
>>
>>  type: OS::Nova::Server
>

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-10 Thread Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
Hi Sergey,

Thanks for your reply.

Thanks for your pointing out that "depends_on" is not needed when we have 
already used "get_attr".

>you create in rg_a some Server and probably it goes to active state before ip 
>address becomes available for get_attr. It is necessary to check, but if it's 
>try to add wait condition for this resource, then you will get created rg_a 
>with fully available resources and I suppose IP will be available

Do you mean that with "depends_on" functionalities, Heat will launch another 
resource group(in my case, "rg_b") as soon as the server in "rg_a" becomes 
"active" state?
Actually, in my real program code, there is  a wait condition, but it is 
located in the server template, not Resource group(in my case, it is "b.yaml), 
which is like:
-- 
rg_a_wc_notify:
type: OS::Heat::SoftwareConfig
properties:
  group: ungrouped
  config:
str_replace:
  template: |
#!/bin/bash -v
wc_notify --data-binary '{"status": "SUCCESS"}'
  params:
wc_notify: {get_attr: [master_wait_handle, curl_cli]}
--
Is it the wait condition which you mentioned in " but if it's try to add wait 
condition for this resource"? or you want this wait condition to be added to 
"a.yaml"(the template declaring resource group)?

And as per my observation, only after Heat receives the signal of "SUCCESS", 
then it try to begin launch "rg_b"(my another server in another resource group).

I am wondering whether there is a chance that, the "IP" information is 
available but Heat doesn't try to get it until the creation of the 2 resource 
groups(rg_a and rg_b) is completed?

Regards,
Gary 

-Original Message-
From: Sergey Kraynev [mailto:skray...@mirantis.com] 
Sent: Wednesday, March 09, 2016 6:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

Hi Gary,


First of all you don't need to use "depends_on", because using "get_attr" 
already create implicit dependency from rg_a.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's expected behavior, because I suppose it 
happens due to:
 - you create in rg_a some Server and probably it goes to active state before 
ip address becomes available for get_attr. It is necessary to check, but if 
it's try to add wait condition for this resource, then you will get created 
rg_a with fully available resources and I suppose IP will be available.

On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) 
<li-gong.d...@hpe.com> wrote:
> Hi,
>
>
>
> I have 3 Heat templates using ResourceGroup. There are 2 resource 
> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires the 
> IP address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip: {get_attr:
> [rg_a, rg_a_public_ip]}” to get the IP address of rg_a both in the 
> section of rg_b parameters (rg_b/properties/resource_def/properties) 
> and the section of outputs.
>
> As per my observation,  rg_a_public_ip shows “null” in the parameter 
> section of rg_b. while rg_a_public_ip shows the correct IP address in 
> the outputs section of the yaml file.
>
>
>
> My questions are:
>
> 1)  Does this behavior is expected as designed or this is a bug?
>
> 2)  What is the alternative solution for the above case(user want to get
> the run-time information of the instance when creating the second 
> resource
> group)  if this behavior is expected?
>
>
>
> --- a.yaml ---
>
> resources:
>
> rg_a:
>
>   type: OS::Heat::ResourceGroup
>
>   properties:
>
>   count: 1
>
>   resource_def:
>
>   type: b.yaml
>
>   properties:
>
>…
>
>
>
> rg_b:
>
> type: OS::Heat::ResourceGroup
>
> depends_on:
>
> -rg_a
>
> properties:
>
> count: 2
>
> resource_def:
>
> type: c.yaml
>
> properties:
>
> rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>   the value is “null”
>
> …
>
>
>
> outputs:
>
>rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
> -  the value is correct.
>
> --
>
>
>
> --b.yaml  
>
> …
>
> resources:
>
> rg_a:
>
> type: OS::Nova::Server
>
> properties:
>
>  …
>
> outputs:
>
>  rg_a_public_ip:
>
>  value: {get_attr: [rg_a, networks, public, 0]}
>
> ---

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-09 Thread Jay Dobies



On 3/9/16 4:39 PM, Zane Bitter wrote:

On 09/03/16 05:42, Sergey Kraynev wrote:

Hi Gary,


First of all you don't need to use "depends_on", because using
"get_attr" already create implicit dependency from rg_a.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's expected behavior, because I
suppose it happens due to:
  - you create in rg_a some Server and probably it goes to active state
before ip address becomes available for get_attr. It is necessary to
check, but if it's try to add wait condition for this resource, then
you will get created rg_a with fully available resources and I suppose
IP will be available.


I would have expected the IP address to be available before the server
becomes CREATE_COMPLETE. If it isn't then I'd consider that a bug too -
as you pointed out, people are relying on the dependency created by
get_attr to ensure that they can actually get the attribute.

cheers,
Zane.


On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
 wrote:

Hi,



I have 3 Heat templates using ResourceGroup. There are 2 resource
groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires
the IP
address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip:
{get_attr:
[rg_a, rg_a_public_ip]}” to get the IP address of rg_a both in the
section
of rg_b parameters (rg_b/properties/resource_def/properties) and the
section
of outputs.

As per my observation,  rg_a_public_ip shows “null” in the parameter
section
of rg_b. while rg_a_public_ip shows the correct IP address in the
outputs
section of the yaml file.



My questions are:

1)  Does this behavior is expected as designed or this is a bug?

2)  What is the alternative solution for the above case(user want
to get
the run-time information of the instance when creating the second
resource
group)  if this behavior is expected?



--- a.yaml ---

resources:

rg_a:

   type: OS::Heat::ResourceGroup

   properties:

   count: 1


Is this still an issue when you remove the resource group and create the 
resource directly? The count of 1 might just be for testing purposes, 
but if that's the end goal you should be able to drop the group entirely.




   resource_def:

   type: b.yaml

   properties:

…



rg_b:

type: OS::Heat::ResourceGroup

depends_on:

 -rg_a

properties:

 count: 2

 resource_def:

 type: c.yaml

 properties:

 rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
  the value is “null”

 …



outputs:

rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
-  the value is correct.

--



--b.yaml  

…

resources:

 rg_a:

type: OS::Nova::Server

properties:

  …

outputs:

  rg_a_public_ip:

  value: {get_attr: [rg_a, networks, public, 0]}

--



-- c.yaml 

parameters:

rg_a_public_ip:

  type: string

  description: IP of rg_a

…

resources:

rg_b:

 type: OS::Nova::Server

 properties:

  …

 outputs:

  …

---



Regards,

Gary




__

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev








__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-09 Thread Zane Bitter

On 09/03/16 05:42, Sergey Kraynev wrote:

Hi Gary,


First of all you don't need to use "depends_on", because using
"get_attr" already create implicit dependency from rg_a.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's expected behavior, because I
suppose it happens due to:
  - you create in rg_a some Server and probably it goes to active state
before ip address becomes available for get_attr. It is necessary to
check, but if it's try to add wait condition for this resource, then
you will get created rg_a with fully available resources and I suppose
IP will be available.


I would have expected the IP address to be available before the server 
becomes CREATE_COMPLETE. If it isn't then I'd consider that a bug too - 
as you pointed out, people are relying on the dependency created by 
get_attr to ensure that they can actually get the attribute.


cheers,
Zane.


On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
 wrote:

Hi,



I have 3 Heat templates using ResourceGroup. There are 2 resource
groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires the IP
address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip: {get_attr:
[rg_a, rg_a_public_ip]}” to get the IP address of rg_a both in the section
of rg_b parameters (rg_b/properties/resource_def/properties) and the section
of outputs.

As per my observation,  rg_a_public_ip shows “null” in the parameter section
of rg_b. while rg_a_public_ip shows the correct IP address in the outputs
section of the yaml file.



My questions are:

1)  Does this behavior is expected as designed or this is a bug?

2)  What is the alternative solution for the above case(user want to get
the run-time information of the instance when creating the second resource
group)  if this behavior is expected?



--- a.yaml ---

resources:

rg_a:

   type: OS::Heat::ResourceGroup

   properties:

   count: 1

   resource_def:

   type: b.yaml

   properties:

…



rg_b:

type: OS::Heat::ResourceGroup

depends_on:

 -rg_a

properties:

 count: 2

 resource_def:

 type: c.yaml

 properties:

 rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
  the value is “null”

 …



outputs:

rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
-  the value is correct.

--



--b.yaml  

…

resources:

 rg_a:

type: OS::Nova::Server

properties:

  …

outputs:

  rg_a_public_ip:

  value: {get_attr: [rg_a, networks, public, 0]}

--



-- c.yaml 

parameters:

rg_a_public_ip:

  type: string

  description: IP of rg_a

…

resources:

rg_b:

 type: OS::Nova::Server

 properties:

  …

 outputs:

  …

---



Regards,

Gary




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev








__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

2016-03-09 Thread Sergey Kraynev
Hi Gary,


First of all you don't need to use "depends_on", because using
"get_attr" already create implicit dependency from rg_a.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's expected behavior, because I
suppose it happens due to:
 - you create in rg_a some Server and probably it goes to active state
before ip address becomes available for get_attr. It is necessary to
check, but if it's try to add wait condition for this resource, then
you will get created rg_a with fully available resources and I suppose
IP will be available.

On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)
 wrote:
> Hi,
>
>
>
> I have 3 Heat templates using ResourceGroup. There are 2 resource
> groups(rg_a and rg_b) and rg_b depends on rg_a.  and rg_b requires the IP
> address of rg_a as the paremeter of rg_b. I use “rg_a_public_ip: {get_attr:
> [rg_a, rg_a_public_ip]}” to get the IP address of rg_a both in the section
> of rg_b parameters (rg_b/properties/resource_def/properties) and the section
> of outputs.
>
> As per my observation,  rg_a_public_ip shows “null” in the parameter section
> of rg_b. while rg_a_public_ip shows the correct IP address in the outputs
> section of the yaml file.
>
>
>
> My questions are:
>
> 1)  Does this behavior is expected as designed or this is a bug?
>
> 2)  What is the alternative solution for the above case(user want to get
> the run-time information of the instance when creating the second resource
> group)  if this behavior is expected?
>
>
>
> --- a.yaml ---
>
> resources:
>
> rg_a:
>
>   type: OS::Heat::ResourceGroup
>
>   properties:
>
>   count: 1
>
>   resource_def:
>
>   type: b.yaml
>
>   properties:
>
>…
>
>
>
> rg_b:
>
> type: OS::Heat::ResourceGroup
>
> depends_on:
>
> -rg_a
>
> properties:
>
> count: 2
>
> resource_def:
>
> type: c.yaml
>
> properties:
>
> rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
>   the value is “null”
>
> …
>
>
>
> outputs:
>
>rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
> -  the value is correct.
>
> --
>
>
>
> --b.yaml  
>
> …
>
> resources:
>
> rg_a:
>
> type: OS::Nova::Server
>
> properties:
>
>  …
>
> outputs:
>
>  rg_a_public_ip:
>
>  value: {get_attr: [rg_a, networks, public, 0]}
>
> --
>
>
>
> -- c.yaml 
>
> parameters:
>
> rg_a_public_ip:
>
>  type: string
>
>  description: IP of rg_a
>
> …
>
> resources:
>
> rg_b:
>
> type: OS::Nova::Server
>
> properties:
>
>  …
>
> outputs:
>
>  …
>
> ---
>
>
>
> Regards,
>
> Gary
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Sergey.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev