Heat engine doesn't detect lbaas listener failures

Bug #1632054 reported by Jiahao liang on 2016-10-10
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Heat
Won't Fix
Medium
Unassigned
octavia
Triaged
High
Zhixin Li

Bug Description

Please refer to the mail-list for comments from other developers, https://openstack.nimeyo.com/97427/openstack-neutron-octavia-doesnt-detect-listener-failures

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.

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.

3. The bug is introduce from here, https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/neutron/lbaas/listener.py#L188. It only checks the provisioning status of the root loadbalancer. However the listener itself has its own provisioning status which may go into ERROR.

4. The same scenario applies for not only listener but also pool, member, healthmonitor, etc., basically every resources except loadbalancer from lbaas.

description: updated
Rabi Mishra (rabi) wrote :

As mentioned in the mail thread you mentioned and confirmed by the lbaas team, this would probably need changes in lbaas first.

- lbaas api should expose provisioning_status for all top level objects (ex. listener)
api
- The suggested status api('show-load-balancer-status-tree'), which could probably be used in the meantime has bugs. Therefore we should probably wait till this is implemented properly in lbaas.

tags: added: lbaas
Changed in neutron:
importance: Undecided → High
Changed in neutron:
status: New → Triaged
Rabi Mishra (rabi) on 2016-11-08
Changed in heat:
milestone: none → next
status: New → Triaged
importance: Undecided → Medium
Michael Johnson (johnsom) wrote :

The work in Octavia is complete for adding provisioning status to all of the objects. We just need to make sure that is available via the APISs and clients.
Provisioning status work was done here: https://review.openstack.org/#/c/372791/

affects: neutron → octavia
Zhixin Li (lizhixin) on 2016-12-02
Changed in heat:
assignee: nobody → Zhixin Li (lizhixin)
Zhixin Li (lizhixin) on 2016-12-02
Changed in octavia:
assignee: nobody → Zhixin Li (lizhixin)
assignee: Zhixin Li (lizhixin) → nobody
Zhixin Li (lizhixin) wrote :

Doesn't it need to add an affected project for neutron-lbaas? We need to expose provisioning_status for all top level objects of lbaas.

Michael Johnson (johnsom) wrote :

The neutron project with lbaas tag was for neutron-lbaas, but now that we have merged the projects, I am removing neutron as it is all under octavia project now.

no longer affects: neutron
Zhixin Li (lizhixin) on 2017-02-26
Changed in octavia:
assignee: nobody → Zhixin Li (lizhixin)
Changed in heat:
assignee: Zhixin Li (lizhixin) → nobody
Rico Lin (rico-lin) on 2017-09-14
Changed in heat:
milestone: next → queens-1
Rico Lin (rico-lin) on 2017-10-25
Changed in heat:
milestone: queens-1 → queens-2
Rico Lin (rico-lin) on 2017-12-06
Changed in heat:
milestone: queens-2 → queens-3
Rico Lin (rico-lin) on 2018-01-29
Changed in heat:
milestone: queens-3 → rocky-1
Rico Lin (rico-lin) on 2018-04-20
Changed in heat:
milestone: rocky-1 → rocky-2
Rabi Mishra (rabi) wrote :

Please use the new octavia resources in heat and report back if you still see the issues.

Changed in heat:
status: Triaged → Won't Fix

Change abandoned by Adam Harwell (<email address hidden>) on branch: master
Review: https://review.opendev.org/405780
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers