Open Stack

On Tue, Sep 27, 2016 at 5:35 PM, Rabi Mishra <ramishra at redhat.com> wrote:

> On Wed, Sep 28, 2016 at 1:01 AM, Zane Bitter <zbitter at redhat.com> wrote:
>
>> On 27/09/16 15:11, Jiahao Liang wrote:
>>
>>> Hello all,
>>>
>>> I am trying to use heat to launch lb resources with Octavia as backend.
>>> The template I used is
>>> from https://github.com/openstack/heat-templates/blob/master/hot/
>>> lbaasv2/lb_group.yaml.
>>>
>>> Following are a few observations:
>>>
>>> 1. Even though Listener was created with ERROR status, heat will still
>>> go ahead and mark it Creation Complete. As in the heat code, it only
>>> check whether root Loadbalancer status is change from PENDING_UPDATE to
>>> ACTIVE. And Loadbalancer status will be changed to ACTIVE anyway no
>>> matter Listener's status.
>>>
>>
>> That sounds like a clear bug.
>>
>
> It seems we're checking for any exceptions from the client[1], before
> checking for the
> loadbalancer status. I could not see any other way to check the listener
> status afterwards.
> Probably a lbaas bug with octavia driver?
>
> Could you please raise a bug with the heat/lbaas logs?
>

> [1]  https://git.openstack.org/cgit/openstack/heat/tree/heat/
> engine/resources/openstack/neutron/lbaas/listener.py#n183
>

 In Octavia, creating resources (listeners, pools, etc.) is an async
operation which it wouldn't raise any exception.
A normal workflow is:
1. heat/neutron client send a create api to Octavia
2. Octavia return a response to client and set the resource to
PENDING_CREATE (no exception will throw to client if the api goes through.)
3. It creation succeeds, Octavia set that resource to ACTIVE; otherwise,
set it to ERROR.

Please correct me if I am wrong.

I will go ahead to raise a bug later if both of you think it necessary.

Thanks,
Jiahao Liang

>
>> 2. As heat engine wouldn't know the Listener's creation failure, it will
>>> continue to create Pool\Member\Heatthmonitor on top of an Listener which
>>> actually doesn't exist. It causes a few undefined behaviors.  As a
>>> result, those LBaaS resources in ERROR state are unable to be cleaned up
>>> with either normal neutron or heat api.
>>>
>>>
>>> Is this a bug regarding LBaaS V2 for heat, or is it designed that way on
>>> purpose?  In my opinion, it would be more natural if heat reports
>>> CREATION_FAILURE if any of the LBaaS resources fails.
>>>
>>> Thanks,
>>> Jiahao Liang
>>>
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.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:unsubscrib
>> e
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160927/b8896026/attachment.html>