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.
Regards,
-sam.
-----Original Message-----
From: Itsuro ODA [mailto:[email protected]]
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
Hi,
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.)
Thanks
--
Itsuro ODA <[email protected]>
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
