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 <sba...@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 <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? >> >> > 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
__________________________________________________________________________ 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