+1 to QUEUED status.
On Fri, Jul 4, 2014 at 5:27 PM, Brandon Logan <brandon.lo...@rackspace.com> wrote: > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
