Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template
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
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
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
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
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 Mishrawrote: >> 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
> 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
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
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 Hardywrote: > 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
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
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
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
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
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
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
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
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
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
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
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
[openstack-dev] [heat] issue of ResourceGroup in Heat template
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