Open Stack

On 26 November 2015 at 12:10, John Garbutt <john at johngarbutt.com> wrote:
> 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.

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