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 >> >> 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
