Open Stack

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

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