Open Stack

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: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

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 <oda at valinux.co.jp>


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev