On 01/08/16 at 12:43pm, John Garbutt wrote:
On 7 January 2016 at 19:59, Matt Riedemann <mrie...@linux.vnet.ibm.com> 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?
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
