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: >>> >>> ... >>> >>> 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 __________________________________________________________________________ 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
