Re: [openstack-dev] [nova] Can we deprecate the server backup API please?
On 11/18/2018 6:51 AM, Alex Xu wrote:
Sounds make sense to me, and then we needn't fix this strange behaviour also https://review.openstack.org/#/c/409644/
The same discussion was had in the spec for that change: https://review.openstack.org/#/c/511825/ Ultimately it amounted to a big "meh, let's just not fix the bug but also no one really cares about deprecating the API either". The only thing deprecating the API would do is signal that it probably shouldn't be used. We would still support it on older microversions. If all anyone cares about is signalling not to use the API then deprecation is probably fine, but I personally don't feel too strongly about it either way. -- Thanks, Matt __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 11/19/2018 08:15 AM, Matt Riedemann wrote:
On 11/18/2018 6:51 AM, Alex Xu wrote:
Sounds make sense to me, and then we needn't fix this strange behaviour also https://review.openstack.org/#/c/409644/
The same discussion was had in the spec for that change:
https://review.openstack.org/#/c/511825/
Ultimately it amounted to a big "meh, let's just not fix the bug but also no one really cares about deprecating the API either".
So we'll let the apathy of the past dictate the actions of the future.
The only thing deprecating the API would do is signal that it probably shouldn't be used. We would still support it on older microversions. If all anyone cares about is signalling not to use the API then deprecation is probably fine, but I personally don't feel too strongly about it either way.
Deprecating these kinds of APIs would, as I mentioned in my original post, signal that the Nova team is actually serious about cleaning up the cruft and getting rid of the debt from years past. And also that it is serious about Nova not being a dumping ground for orchestration and out-of-scope APIs not related to a Compute API. Best, -jay
---- On Mon, 19 Nov 2018 22:36:40 +0900 Jay Pipes <jaypipes@gmail.com> wrote ----
On 11/19/2018 08:15 AM, Matt Riedemann wrote:
On 11/18/2018 6:51 AM, Alex Xu wrote:
Sounds make sense to me, and then we needn't fix this strange behaviour also https://review.openstack.org/#/c/409644/
The same discussion was had in the spec for that change:
+1 for deprecating those APIs. Current spec indicate the backup create API only which we can update to include image create also. -gmann
Ultimately it amounted to a big "meh, let's just not fix the bug but also no one really cares about deprecating the API either".
So we'll let the apathy of the past dictate the actions of the future.
The only thing deprecating the API would do is signal that it probably shouldn't be used. We would still support it on older microversions. If all anyone cares about is signalling not to use the API then deprecation is probably fine, but I personally don't feel too strongly about it either way.
Deprecating these kinds of APIs would, as I mentioned in my original post, signal that the Nova team is actually serious about cleaning up the cruft and getting rid of the debt from years past.
And also that it is serious about Nova not being a dumping ground for orchestration and out-of-scope APIs not related to a Compute API.
Best, -jay
On Mon, 19 Nov 2018 08:36:40 -0500, Jay Pipes wrote:
On 11/19/2018 08:15 AM, Matt Riedemann wrote:
On 11/18/2018 6:51 AM, Alex Xu wrote:
Sounds make sense to me, and then we needn't fix this strange behaviour also https://review.openstack.org/#/c/409644/
The same discussion was had in the spec for that change:
https://review.openstack.org/#/c/511825/
Ultimately it amounted to a big "meh, let's just not fix the bug but also no one really cares about deprecating the API either".
So we'll let the apathy of the past dictate the actions of the future.
FWIW, my point of view on deprecating the API was/is, if people are using it to accomplish some task, why deprecate it if it's not hurting anything else? That is, I didn't want the aforementioned spec to amount to something like, someone proposes to fix a strange behavior they observed using the API and our answer is to deprecate the entire API. If it's clear that no one is using or benefiting from the API, then I am in support of deprecating it. But I haven't felt certain about whether that's the case so far.
The only thing deprecating the API would do is signal that it probably shouldn't be used. We would still support it on older microversions. If all anyone cares about is signalling not to use the API then deprecation is probably fine, but I personally don't feel too strongly about it either way.
Deprecating these kinds of APIs would, as I mentioned in my original post, signal that the Nova team is actually serious about cleaning up the cruft and getting rid of the debt from years past.
And also that it is serious about Nova not being a dumping ground for orchestration and out-of-scope APIs not related to a Compute API.
That's fair enough, and if we can get a quick confirmation from operators we know (CERN, NeCTAR, Oath, Vexxhost, OVH, etc) that they don't use the API, I agree we should go ahead and deprecate it for the reasons you mention. -melanie
On Tue, Nov 20, 2018 at 5:35 AM melanie witt <melwittt@gmail.com> wrote:
On Mon, 19 Nov 2018 08:36:40 -0500, Jay Pipes wrote:
On 11/19/2018 08:15 AM, Matt Riedemann wrote:
On 11/18/2018 6:51 AM, Alex Xu wrote:
Sounds make sense to me, and then we needn't fix this strange behaviour also https://review.openstack.org/#/c/409644/
The same discussion was had in the spec for that change:
https://review.openstack.org/#/c/511825/
Ultimately it amounted to a big "meh, let's just not fix the bug but also no one really cares about deprecating the API either".
So we'll let the apathy of the past dictate the actions of the future.
FWIW, my point of view on deprecating the API was/is, if people are using it to accomplish some task, why deprecate it if it's not hurting anything else? That is, I didn't want the aforementioned spec to amount to something like, someone proposes to fix a strange behavior they observed using the API and our answer is to deprecate the entire API.
If it's clear that no one is using or benefiting from the API, then I am in support of deprecating it. But I haven't felt certain about whether that's the case so far.
The only thing deprecating the API would do is signal that it probably shouldn't be used. We would still support it on older microversions. If all anyone cares about is signalling not to use the API then deprecation is probably fine, but I personally don't feel too strongly about it either way.
Deprecating these kinds of APIs would, as I mentioned in my original post, signal that the Nova team is actually serious about cleaning up the cruft and getting rid of the debt from years past.
And also that it is serious about Nova not being a dumping ground for orchestration and out-of-scope APIs not related to a Compute API.
That's fair enough, and if we can get a quick confirmation from operators we know (CERN, NeCTAR, Oath, Vexxhost, OVH, etc) that they don't use the API, I agree we should go ahead and deprecate it for the reasons you mention.
Oath doesn't have any internal documentation or regression testing around the backup API - I can't guarantee it isn't used, but I think we'd be fine with it going away. // jim
I don’t think this is at use at CERN either. We use Mistral’s cron to schedule the backups if needed. Tim From: Jim Rollenhagen <jim@jimrollenhagen.com> Date: Tuesday, 20 November 2018 at 16:19 To: "melwittt@gmail.com" <melwittt@gmail.com> Cc: "openstack-discuss@lists.openstack.org" <openstack-discuss@lists.openstack.org> Subject: Re: [openstack-dev] [nova] Can we deprecate the server backup API please? On Tue, Nov 20, 2018 at 5:35 AM melanie witt <melwittt@gmail.com<mailto:melwittt@gmail.com>> wrote: On Mon, 19 Nov 2018 08:36:40 -0500, Jay Pipes wrote:
On 11/19/2018 08:15 AM, Matt Riedemann wrote:
On 11/18/2018 6:51 AM, Alex Xu wrote:
Sounds make sense to me, and then we needn't fix this strange behaviour also https://review.openstack.org/#/c/409644/
The same discussion was had in the spec for that change:
https://review.openstack.org/#/c/511825/
Ultimately it amounted to a big "meh, let's just not fix the bug but also no one really cares about deprecating the API either".
So we'll let the apathy of the past dictate the actions of the future.
FWIW, my point of view on deprecating the API was/is, if people are using it to accomplish some task, why deprecate it if it's not hurting anything else? That is, I didn't want the aforementioned spec to amount to something like, someone proposes to fix a strange behavior they observed using the API and our answer is to deprecate the entire API. If it's clear that no one is using or benefiting from the API, then I am in support of deprecating it. But I haven't felt certain about whether that's the case so far.
The only thing deprecating the API would do is signal that it probably shouldn't be used. We would still support it on older microversions. If all anyone cares about is signalling not to use the API then deprecation is probably fine, but I personally don't feel too strongly about it either way.
Deprecating these kinds of APIs would, as I mentioned in my original post, signal that the Nova team is actually serious about cleaning up the cruft and getting rid of the debt from years past.
And also that it is serious about Nova not being a dumping ground for orchestration and out-of-scope APIs not related to a Compute API.
That's fair enough, and if we can get a quick confirmation from operators we know (CERN, NeCTAR, Oath, Vexxhost, OVH, etc) that they don't use the API, I agree we should go ahead and deprecate it for the reasons you mention. Oath doesn't have any internal documentation or regression testing around the backup API - I can't guarantee it isn't used, but I think we'd be fine with it going away. // jim
participants (6)
-
Ghanshyam Mann
-
Jay Pipes
-
Jim Rollenhagen
-
Matt Riedemann
-
melanie witt
-
Tim Bell