Open Stack

On 24 November 2015 at 16:36, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
> I know in Vancouver we talked about no more soft delete and in Mitaka lxsli
> decoupled the nova models from the SoftDeleteMixin [1].
>
> From what I remember, the idea is to not add the deleted column to new
> tables, to not expose soft deleted resources in the REST API in new ways,
> and to eventually drop the deleted column from the models.
>
> I bring up the REST API because I was tinkering with the idea of allowing
> non-admins to list/show their (soft) deleted instances [2]. Doing that,
> however, would expose more of the REST API to deleted resources which makes
> it harder to remove from the data model.
>
> My question is, how were we thinking we were going to remove the deleted
> column from the data model in a backward compatible way? A new microversion
> in the REST API isn't going to magically work if we drop the column in the
> data model, since anything before that microversion should still work - like
> listing deleted instances for the admin.
>
> Am I forgetting something? There were a lot of ideas going around the room
> during the session in Vancouver and I'd like to sort out the eventual
> long-term plan so we can document it in the devref about policies so that
> when ideas like [2] come up we can point to the policy and say 'no we aren't
> going to do that and here's why'.
>
> [1]
> http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/no-more-soft-delete.html
> [2]
> https://blueprints.launchpad.net/nova/+spec/non-admin-list-deleted-instances

>From my memory, step 1 is to ensure we don't keep adding soft delete
by default/accident, which is where the explicit mix-in should help.

Step 2, is removing existing soft_deletes. Now we can add a new
microversion to remove the concept of requesting deleted things, but
as you point out, that doesn't help the older microversions.

What we could raise 403 errors when users request deleted things in
older versions of the API. I don't like that breaking API change, but
I also don't like the idea of keeping soft_delete in the database for
ever. Its a the case of picking the best of two bad outcomes. I am not
sure we have reached consensus on the preferred approach yet.

Thanks,
johnthetubaguy