Open Stack

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.duan at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>