Open Stack

+1 to QUEUED status.


On Fri, Jul 4, 2014 at 5:27 PM, Brandon Logan <brandon.logan at 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.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
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140707/a760ca2e/attachment.html>