[openstack-dev] [Neutron][LBaaS][FWaaS][VPN] Admin status vs operational status
SamuelB at Radware.com
Tue Mar 18 17:34:32 UTC 2014
Discussing some "radical" concepts...
I also agree that there should be different attribute to reflect the administrator state, operation state and the "provisioning" state.
This is already reflected in https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit?usp=sharing as three different properties "admin_state_up", "Provisioning Status" and "Operation Status".
The problem with the "provisioning" status is that it is not "reentrant"
Many of the APIs are a-sync so if we do a few a-sync calls, it is not clear which of those call's status we see in the status property.
A better API might be that when doing an a-sync call, the call retunes a "token" and the status of the "token" reflects how the a-sync call was completed.
From: Itsuro ODA [mailto:oda at valinux.co.jp]
Sent: Tuesday, March 18, 2014 1:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPN] Admin status vs operational status
With my understanding, it should be:
* 'status' is a read only attribute which shows to users whether
the service is available or not.
So for example, "VIP status is ACTIVE but the loadblancing service
is not available" is not allowed.
(Actually our customers want to fix this strongly.)
* 'admin_state_up' is an attribute for an administrator to set
whether the service is available or not.
As a result 'status' of the resource and the associated resources
become ACTIVE or DOWN.
(If it does not work so, it is a problem of the implementation.)
Itsuro ODA <oda at valinux.co.jp>
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev