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

Reply via email to