Hi German, That actually brings up another thing that needs to be done. There is no DELETED state. When an entity is deleted, it is deleted from the database. I'd prefer a DELETED state so that should be another feature we implement afterwards.
Thanks, Brandon On Thu, 2014-07-03 at 23:02 +0000, Eichberger, German wrote: > 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.miramon...@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.tooh...@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.lo...@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@lists.openstack.org > >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > >_______________________________________________ > >OpenStack-dev mailing list > >OpenStack-dev@lists.openstack.org > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
