Open Stack

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.

>
>> 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev