Open Stack

On 11/26/2015 6:17 AM, John Garbutt wrote:
> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

What is the main reason again for removing soft deleted (deleted != 0) 
resources? Because of DB bloat? If that's the case, aren't operators 
pretty used to archiving/purging by now? Granted, the in-tree archive 
command is broken, and I'm working on fixing that, and we have a change 
up to add a purge command for (soft) deleted instances, but I'm trying 
to see if I'm forgetting something else here.

It's like soft delete is a Frankenstein and we're a mob out to kill it, 
but I forget every 6 months exactly why, and if it's totally necessary 
(and worth backward incompatible API changes). I think that's a question 
that operators and users should really answer rather than the nova dev team.

-- 

Thanks,

Matt Riedemann