Open Stack

IMHO I think it's a great way to fix the URI problem.
+1

Belmiro

On Fri, Jan 8, 2016 at 3:23 PM, Sylvain Bauza <sbauza at redhat.com> wrote:

>
>
> 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
>>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160108/5b5f4f0c/attachment.html>