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