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
