Hi folks, Yes, I think there are some discrepancies around the provisioning status being exposed. Currently I think the only way to get visibility to those is through the status api: http://developer.openstack.org/api-ref/networking/v2/#show-load-balancer-status-tree Which, frankly, I think there are some bugs in. Going forward we do want to flesh these out and expose them as appropriate. My intent is to have provisioning status on all of our top level objects that can independently go into an ERROR state should there be a problem. This should allow users/operators the ability to delete/re-create any object that had a failure the driver was unable to recover from. If you see gaps or items you need visibility to, please open bugs for us and extra credit if you ping us in the #openstack-lbaas channel or during our weekly meeting. Michael On Wed, Sep 28, 2016 at 10:51 AM, Jiahao Liang <jiahao.liang at oneconvergence.com> wrote: > But in the lbaas db, all lbaas resources have the provisioning_status and > operating_status fields[1]. > [1]http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/neutron_lbaas/db/loadbalancer/models.py#n352 > > Also there are apis which allows drivers to maintain them[2]. > [2]http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/neutron_lbaas/agent/agent_manager.py#n255 > > __________________________________________________________________________ > 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 >