On 11/26/2015 6:17 AM, John Garbutt wrote:
On 26 November 2015 at 12:10, John Garbutt <j...@johngarbutt.com> wrote:
On 24 November 2015 at 16:36, Matt Riedemann <mrie...@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-requ...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
