On 26 November 2015 at 12:10, John Garbutt <[email protected]> wrote: > On 24 November 2015 at 16:36, Matt Riedemann <[email protected]> > 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.
I just realised, my text is ambiguous... There is a difference between soft deleted instances, and soft delete in the DB. If the instance could still be restored, and is not yet deleted, it makes sense that policy could allow a non-admin to see those. But thats a non-db-deleted instance in the SOFT_DELETED state. I am still leaning towards killing the APIs that allow you to read in DB soft-deleted data. Although, in some ways thats because the API changes based on the DB retention policy of the deployer, which seems very odd. Thanks, johnthetubaguy __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
