[openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend

Eichberger, German german.eichberger at hp.com
Thu Jul 3 23:02:42 UTC 2014


Hi Jorge,

+1 for QUEUED and DETACHED

I would suggest to make the time how long we keep entities in DELETED state configurable. We use something like 30 days, too, but we have made it configurable to adapt to changes...

German

-----Original Message-----
From: Jorge Miramontes [mailto:jorge.miramontes at RACKSPACE.COM] 
Sent: Thursday, July 03, 2014 11:59 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend

+1 to QUEUED status.

For entities that have the concept of being attached/detached why not have a 'DETACHED' status to indicate that the entity is not provisioned at all (i.e. The config is just stored in the DB). When it is attached during provisioning then we can set it to 'ACTIVE' or any of the other provisioning statuses such as 'ERROR', 'PENDING_UPDATE', etc. Lastly, it wouldn't make much sense to have a 'DELETED' status on these types of entities until the user actually issues a DELETE API request (not to be confused with detaching). Which begs another question, when items are deleted how long should the API return responses for that resource? We have a 90 day threshold for this in our current implementation after which the API returns 404's for the resource.

Cheers,
--Jorge




On 7/3/14 10:39 AM, "Phillip Toohill" <phillip.toohill at RACKSPACE.COM>
wrote:

>If the objects remain in 'PENDING_CREATE' until provisioned it would 
>seem that the process got stuck in that status and may be in a bad 
>state from user perspective. I like the idea of QUEUED or similar to 
>reference that the object has been accepted but not provisioned.
>
>Phil
>
>On 7/3/14 10:28 AM, "Brandon Logan" <brandon.logan at RACKSPACE.COM> wrote:
>
>>With the new API and object model refactor there have been some issues 
>>arising dealing with the status of entities.  The main issue is that 
>>Listener, Pool, Member, and Health Monitor can exist independent of a 
>>Load Balancer.  The Load Balancer is the entity that will contain the 
>>information about which driver to use (through provider or flavor).  
>>If a Listener, Pool, Member, or Health Monitor is created without a 
>>link to a Load Balancer, then what status does it have?  At this point 
>>it only exists in the database and is really just waiting to be 
>>provisioned by a driver/backend.
>>
>>Some possibilities discussed:
>>A new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name 
>>Entities just remain in PENDING_CREATE until provisioned by a driver 
>>Entities just remain in ACTIVE until provisioned by a driver
>>
>>Opinions and suggestions?
>>_______________________________________________
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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



More information about the OpenStack-dev mailing list