Open Stack

On 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
> 

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