I'll +1 UNBOUND or DEFERRED status. QUEUED does have a kind of implication that it will be provisioned without any further action whereas UNBOUND or DEFERRED imply that another action must take place for it to actually be provisioned.
Thanks, Brandon ________________________________________ From: Jorge Miramontes [jorge.miramon...@rackspace.com] Sent: Monday, July 07, 2014 12:02 PM 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 Hey Mark, To add, one reason we have a DELETED status at Rackspace is that certain sub-resources are still relevant to our customers. For example, we have a usage sub-resource which reveals usage records for the load balancer. To illustrate, a user issues a DELETE on /loadbalancers/<id> but can still issue a GET on /loadbalancers/<id>/usage. If /loadbalancers/<id> were truly deleted (i.e a 404 is returned) it wouldn't make RESTful sense to expose the usage sub-resource. Furthermore, even if we don't plan on having sub-resources that a user will actually query I would still like a DELETED status as our customers use it for historical and debugging purposes. It provides users with a sense of clarity and doesn't leave them scratching their heads thinking, "How were those load balancers configured when we had that issue the other day?" for example. I agree on your objection for unattached objects assuming API operations for these objects will be synchronous in nature. However, since the API is suppose to be asynchronous a QUEUED status will make sense for the API operations that are truly asynchronous. In an earlier email I stated that a QUEUED status would be beneficial when compared to just a BUILD status because it would allow for more accurate metrics in regards to provisioning time. Customers will complain more if it appears provisioning times are taking a long time when in reality they are actually queued do to high API traffic. Thoughts? Cheers, --Jorge On 7/7/14 9:32 AM, "Mark McClain" <mmccl...@yahoo-inc.com> wrote: > >On 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 >> > >This is an interesting discussion since we would create an API >inconsistency around possible status values. Traditionally, status has >been be fabric status and we have not always well defined what the values >should mean to tenants. Given that this is an extension, I think that >adding new values would be ok (Salvatore might have a different opinion >than me). > >Right we¹ve never had a deleted state because the record has been removed >immediately in most implementations even if the backend has not fully >cleaned up. I was thinking for the v3 core we should have a DELETING >state that is set before cleanup is dispatched to the backend >driver/worker. The record can then be deleted when the backend has >cleaned up. > >For unattached objects, I¹m -1 on QUEUED because some will interpret that >the system is planning to execute immediate operations on the resource >(causing customer queries/complaints about why it has not transitioned). >Maybe use something like DEFERRED, UNBOUND, or VALIDATED? > >mark >_______________________________________________ >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
