Re: [openstack-dev] [Openstack-operators] [nova][cells] Should flavors in the API DB for cells v2 be soft-deletable?
On 7 January 2016 at 19:59, Matt Riedemann 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. > 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. > 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. > 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
Re: [openstack-dev] [Openstack-operators] [nova][cells] Should flavors in the API DB for cells v2 be soft-deletable?
On 01/08/16 at 12:43pm, John Garbutt wrote: On 7 January 2016 at 19:59, Matt Riedemann 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//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//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-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
Re: [openstack-dev] [Openstack-operators] [nova][cells] Should flavors in the API DB for cells v2 be soft-deletable?
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 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//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//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 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
Re: [openstack-dev] [Openstack-operators] [nova][cells] Should flavors in the API DB for cells v2 be soft-deletable?
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 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 >>> 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//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//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 > o
Re: [openstack-dev] [Openstack-operators] [nova][cells] Should flavors in the API DB for cells v2 be soft-deletable?
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 >> 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//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//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 __ 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