Open Stack

2015-11-30 19:42 GMT+08:00 Sean Dague <sean at dague.net>:

> On 11/24/2015 11:36 AM, Matt Riedemann 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
> >
> >
>
> On the API compat side. There is no contract with the user for how long
> deleted items will be shown, or how old the deleted history is.
>
> The contract semantics are:
>
> * by default - don't show me anything that's deleted
> * with a flag - ok, you can *also* show me deleted things
>
> The one places soft deleted removal is going to be semantically
> meaningful is on GET /servers/details?changes-since=....
>
> Because in that case it's used by most people as a journal, and includes
> deleted instances. It's our janky event stream for servers (given that
> we have no other real event stream). That would need something better
> before we make that query not possible.
>
> I also agree, it's not clear to me why removing soft delete off of
> things like instances is hugely critical. I think getting rid of it as
> default for new things is good. But some places it's pretty intrinsic to
> the information people pull out.
>

+1, for user to check out the history, query the deleted instance sounds
like useful.

For showing the deleted instance for non-admin user, looks like it's hard
for operator to make promise to user that how long the deleted instance can
be queried anymore. Currently the db archive just archive all the entries,
whatever it was deleted long time ago, or just in seconds. We probably can
add some filter to db archive call. But anyway this is another thing. Also
want to figure out why query deleted instance is useless first.


>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151130/2e5155e8/attachment.html>