[openstack-dev] [Neutron][LBaaS] Object status and admin_state_up

Eugene Nikanorov enikanorov at mirantis.com
Tue Oct 29 16:11:32 UTC 2013


That's right, it is driver-specific, but we can come up with a generic
guideline for this.
Also, I'm interested in preferred solution for HAProxy.

Thanks,
Eugene.


On Tue, Oct 29, 2013 at 6:43 PM, Avishay Balderman <AvishayB at radware.com>wrote:

>  Hi****
>
> It feels like a driver specific topic.****
>
> So I am not sure we  can come to a generic solution in the lbaas core code.
> ****
>
> Thanks****
>
> Avishay****
>
> ** **
>
> *From:* Eugene Nikanorov [mailto:enikanorov at mirantis.com]
> *Sent:* Tuesday, October 29, 2013 11:19 AM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [Neutron][LBaaS] Object status and
> admin_state_up****
>
> ** **
>
> Hi folks,****
>
> ** **
>
> Currently there are two attributes of vips/pools/members that represent a
> status: 'status' and 'admin_state_up'.****
>
> ** **
>
> The first one is used to represent deployment status and can be
> PENDING_CREATE, ACTIVE, PENDING_DELETE, ERROR.****
>
> We also have admin_state_up which could be True or False.****
>
> ** **
>
> I'd like to know your opinion on how to change 'status' attribute based on
> admin_state_up changes.****
>
> For instance. If admin_state_up is updated to be False, how do you think
> 'status' should change?****
>
> ** **
>
> Also, speaking of reference implementation (HAProxy), changing vip or pool
> admin_state_up to False effectively destroys the balancer (undeploys it),
> while the objects remain in ACTIVE state.****
>
> There are two options to fix this discrepancy:****
>
> 1) Change status of vip/pool to PENDING_CREATE if admin_state_up changes
> to False****
>
> 2) Don't destroy the loadbalancer and use HAProxy capability to disable
> frontend and backend while leave vip/pool in ACTIVE state****
>
> ** **
>
> Please share your opinion.****
>
> ** **
>
> Thanks,****
>
> Eugene.****
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131029/b5c22a15/attachment.html>


More information about the OpenStack-dev mailing list