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:enikano...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
