<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">+1 to QUEUED status.</span><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 4, 2014 at 5:27 PM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi German,<br>
<br>
That actually brings up another thing that needs to be done. There is<br>
no DELETED state. When an entity is deleted, it is deleted from the<br>
database. I'd prefer a DELETED state so that should be another feature<br>
we implement afterwards.<br>
<br>
Thanks,<br>
Brandon<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, 2014-07-03 at 23:02 +0000, Eichberger, German wrote:<br>
> Hi Jorge,<br>
><br>
> +1 for QUEUED and DETACHED<br>
><br>
> 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...<br>
><br>
> German<br>
><br>
> -----Original Message-----<br>
> From: Jorge Miramontes [mailto:<a href="mailto:jorge.miramontes@RACKSPACE.COM">jorge.miramontes@RACKSPACE.COM</a>]<br>
> Sent: Thursday, July 03, 2014 11:59 AM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend<br>
><br>
> +1 to QUEUED status.<br>
><br>
> 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.<br>
><br>
> Cheers,<br>
> --Jorge<br>
><br>
><br>
><br>
><br>
> On 7/3/14 10:39 AM, "Phillip Toohill" <<a href="mailto:phillip.toohill@RACKSPACE.COM">phillip.toohill@RACKSPACE.COM</a>><br>
> wrote:<br>
><br>
> >If the objects remain in 'PENDING_CREATE' until provisioned it would<br>
> >seem that the process got stuck in that status and may be in a bad<br>
> >state from user perspective. I like the idea of QUEUED or similar to<br>
> >reference that the object has been accepted but not provisioned.<br>
> ><br>
> >Phil<br>
> ><br>
> >On 7/3/14 10:28 AM, "Brandon Logan" <<a href="mailto:brandon.logan@RACKSPACE.COM">brandon.logan@RACKSPACE.COM</a>> wrote:<br>
> ><br>
> >>With the new API and object model refactor there have been some issues<br>
> >>arising dealing with the status of entities. The main issue is that<br>
> >>Listener, Pool, Member, and Health Monitor can exist independent of a<br>
> >>Load Balancer. The Load Balancer is the entity that will contain the<br>
> >>information about which driver to use (through provider or flavor).<br>
> >>If a Listener, Pool, Member, or Health Monitor is created without a<br>
> >>link to a Load Balancer, then what status does it have? At this point<br>
> >>it only exists in the database and is really just waiting to be<br>
> >>provisioned by a driver/backend.<br>
> >><br>
> >>Some possibilities discussed:<br>
> >>A new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name<br>
> >>Entities just remain in PENDING_CREATE until provisioned by a driver<br>
> >>Entities just remain in ACTIVE until provisioned by a driver<br>
> >><br>
> >>Opinions and suggestions?<br>
> >>_______________________________________________<br>
> >>OpenStack-dev mailing list<br>
> >><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> >><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> >_______________________________________________<br>
> >OpenStack-dev mailing list<br>
> ><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>