Open Stack

On 01/08/2016 09:10 AM, Andrew Laski wrote:
> On 01/08/16 at 12:43pm, John Garbutt wrote:
>> On 7 January 2016 at 19:59, Matt Riedemann
>> <mriedem at 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.

I agree. Our old contract was essentially:

* you can have access to deleted flavors if you know the id, until such
time that you can't because it was actually purged.

Making the 'until such time' go to 0 seems fine.

>>> 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?

I've proposed https://review.openstack.org/#/c/265282/ as the spec for
this change. Once you stare at the attributes in flavors, a bunch of
them really aren't needed once it becomes a sub resource.

	-Sean

-- 
Sean Dague
http://dague.net