Le 08/01/2016 15:10, Andrew Laski a écrit :
On 01/08/16 at 12:43pm, John Garbutt wrote:
On 7 January 2016 at 19:59, Matt Riedemann
<[email protected]> wrote:
There is a cells v2 change up for review [1] which creates the
flavor tables
in the API DB.
I noted that those table definitions include the soft-delete columns
(deleted and deleted_at), which at the YVR summit and in other
threads [2]
we've said we're not doing anymore for new tables.
The point raised to keep them soft-deletable is that the flavor API
allows
showing soft-deleted flavors if you know the id [3]. And you can get
the
flavor id for an instance (we always store the flavor info that was
used to
boot the instance).
The question is, can we break that wrinkle in the API by not allow
soft-deleting the flavor in the API DB?
On balance, I think this is OK.
There's an alternate approach to this that we can take which I'll
outline below. But it should meet the needs of anyone currently
looking up deleted flavors.
Note that in the normal nova DB, if the admin archives/purges the
instance_types table, the wrinkle is already broken because the
soft-deleted
flavor is now hard-deleted, but that's maybe not a great
justification for
consciously removing this support in the API DB.
This is what won me over. All be it, reluctantly.
I think this is good justification for removing the ability because
currently it is essentially undefined behavior. Requesting a deleted
flavor may or may not work and either response is correct.
If we made the flavor soft-deletable in the API DB, one issue is we
don't
have an in-tree entrypoint for cleaning this up (there are no
archive/purge
CLIs for the API DB). We could always add that, but it's not there
right
now.
Another thing that came up in the cells meeting this week is that if we
didn't make the flavor soft-deletable, we could still show the flavor
information for a given instance via the server GET API. However,
that would
be a microversion change to show the full flavor information for the
server
rather than just the flavor id.
This is really only possible because we now store flavor info inside
every instance object.
I think before that, deleting the flavor would make some instance
operations fail.
Because we now store flavor info with each instance it opens up the
following possibility:
Currently the flavor portion of an instance show request looks like
"flavor": {"id": "8", "links": [{"href":
"https://example.com/flavors/8";, "rel": "bookmark"}]}
If that were instead changed to return
"https://example.com/servers/<uuid>/flavor" as the link and we exposed
the flavor information stored with the instance on that endpoint then
we no longer need to expose deleted flavors.
So for an instance booted with flavor 8 https://example.com/flavors/8
would be equivalent to https://example.com/servers/<uuid>/flavor
except that the latter would be available even if flavor 8 were deleted.
Does that seem like an acceptable path for users?
Yes, that's something we discussed on IRC yesterday which I think would
be very good. It means a microversion but it means that operators would
be very happy because if a flavor is removed, the flavor URI would still
be working.
+1000 to that.
-Sylvain
Thoughts? I'm cross-posting this to -dev and the -operators list to
see what
kind of user impact there would be if we didn't soft-delete flavors
in the
API DB (so you couldn't look up deleted flavors in the API).
In balance, I think we should not allow soft_delete of flavors in the
API DB.
In a related note, and I thinking about a backlog spec looking at a
flavor lifecycle. Thinking about early release, to production, then
phasing out of flavors. I don't think soft delete is needed for that.
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
