Open Stack

Hi,

I think that the current implementation is fine.
This are two different aspects.
The status describes whether the last a-sync activity is active or whether it is not.
The admin status describes what the user wishes for the object status to be.

Follows an example: If I update the VIP with admin status down, the status should be moved to PENDING_UPDATE, when the driver implements this than the status with be back to being ACTIVE.
The Term ACTIVE, might be wrong in that it might be renamed to something like APPLIED.

Regards,
                -Sam.



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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131031/b0a24266/attachment.html>