[nova] Status of the bp support-move-ops-with-qos-ports
Hi, As feature freeze is closing in I try to raise awareness of the implementation status of the support-move-ops-with-qos-ports<https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/support-move-ops-with-qos-ports> bp [1]. The original goal of the bp was to support every move operations (cold migrate, resize, live-migrate, evacuate, unshelve). Today I have ready and tested (unit + functional) patches proposed for cold migrate and resize [2]. I don't think every move operations will be ready and merged in Train but I still hope that there is a chance for cold migrate and resize to land. Sure I will continue working on supporting the operations that miss the Train in the U release. One possible complication in the current patch series is that it proposes the necessary RPC changes for _every_ move operations [3]. This might not be what we want to merge in Train if only cold migrate and resize support fill fit. So I see two possible way forwards: a) Others also feel that cold migrate and resize will fit into Train, and then I will quickly change [3] to only modify those RPCs. b) We agree to postpone the whole series to U. Then I will not spend too much time on reworking [3] in the Train timeframe. A connected topic: I proposed patches [4] to add cold migrate and resize tempest coverage to the nova-grenade-multinode (renamed from nova-grenade-live-migrate) job as Matt pointed out in [3] that we don't have such coverage and that my original change in [3] would have broken a mixed-compute-version deployment. Any feedback is appreciated. Cheers, gibi [1] https://specs.openstack.org/openstack/nova-specs/specs/train/approved/suppor... [2] https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports [3] https://review.opendev.org/#/c/655721 [4] https://review.opendev.org/#/c/679210
On 8/29/2019 10:45 AM, Balázs Gibizer wrote:
As feature freeze is closing in I try to raise awareness of the implementation status of the support-move-ops-with-qos-ports <https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/support-move-ops-with-qos-ports> bp [1].
Thanks for this since I know you've been pushing patches but I haven't been able to get myself past the hump that is [3] yet.
The original goal of the bp was to support every move operations (cold migrate, resize, live-migrate, evacuate, unshelve). Today I have ready and tested (unit + functional) patches proposed for cold migrate and resize [2]. I don't think every move operations will be ready and merged in Train but I still hope that there is a chance for cold migrate and resize to land. Sure I will continue working on supporting the operations that miss the Train in the U release.
This is probably OK since we agreed at the PTG that this blueprint was essentially going to be closing gaps in functionality introduced in Stein but not adding a new microversion, correct? If so, then doing it piece-meal seems OK to me.
One possible complication in the current patch series is that it proposes the necessary RPC changes for _every_ move operations [3]. This might not be what we want to merge in Train if only cold migrate and resize support fill fit. So I see two possible way forwards: a) Others also feel that cold migrate and resize will fit into Train, and then I will quickly change [3] to only modify those RPCs. b) We agree to postpone the whole series to U. Then I will not spend too much time on reworking [3] in the Train timeframe.
Or (c) we just land that change. I was meaning to review that today anyway so this email is coincidental for me. I think passing the request spec down to the compute methods is fine and something we'll want to do eventually anyway for this series (even if the live migration stuff is deferred to U).
A connected topic: I proposed patches [4] to add cold migrate and resize tempest coverage to the nova-grenade-multinode (renamed from nova-grenade-live-migrate) job as Matt pointed out in [3] that we don't have such coverage and that my original change in [3] would have broken a mixed-compute-version deployment.
I'm just waiting on CI results for those but since I've already been through them in some form and they are pretty small I think there is a good chance of landing these soon. -- Thanks, Matt
On Thu, Aug 29, 2019 at 6:15 PM Matt Riedemann <mriedemos@gmail.com> wrote:
On 8/29/2019 10:45 AM, Balázs Gibizer wrote:
As feature freeze is closing in I try to raise awareness of the implementation status of the support-move-ops-with-qos-ports < https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/support-move-ops-with-qos-ports> bp
[1].
Thanks for this since I know you've been pushing patches but I haven't been able to get myself past the hump that is [3] yet.
The original goal of the bp was to support every move operations (cold migrate, resize, live-migrate, evacuate, unshelve). Today I have ready and tested (unit + functional) patches proposed for cold migrate and resize [2]. I don't think every move operations will be ready and merged in Train but I still hope that there is a chance for cold migrate and resize to land. Sure I will continue working on supporting the operations that miss the Train in the U release.
This is probably OK since we agreed at the PTG that this blueprint was essentially going to be closing gaps in functionality introduced in Stein but not adding a new microversion, correct? If so, then doing it piece-meal seems OK to me.
Yeah, and it's already pretty clear about which specific operations can be done. I'm OK with having only a few operations done by Train given the API and the docs are correctly explaining which ones.
One possible complication in the current patch series is that it proposes the necessary RPC changes for _every_ move operations [3]. This might not be what we want to merge in Train if only cold migrate and resize support fill fit. So I see two possible way forwards: a) Others also feel that cold migrate and resize will fit into Train, and then I will quickly change [3] to only modify those RPCs. b) We agree to postpone the whole series to U. Then I will not spend too much time on reworking [3] in the Train timeframe.
Or (c) we just land that change. I was meaning to review that today anyway so this email is coincidental for me. I think passing the request spec down to the compute methods is fine and something we'll want to do eventually anyway for this series (even if the live migration stuff is deferred to U).
+1 FWIW, since 3 years I would like to pass the RequestSpec down to the compute but I hadn't time to do it yet. Cool with me.
A connected topic: I proposed patches [4] to add cold migrate and resize tempest coverage to the nova-grenade-multinode (renamed from nova-grenade-live-migrate) job as Matt pointed out in [3] that we don't have such coverage and that my original change in [3] would have broken a mixed-compute-version deployment.
I'm just waiting on CI results for those but since I've already been through them in some form and they are pretty small I think there is a good chance of landing these soon.
--
Thanks,
Matt
On Fri, 2019-08-30 at 10:06 +0200, Sylvain Bauza wrote:
On Thu, Aug 29, 2019 at 6:15 PM Matt Riedemann <mriedemos@gmail.com> wrote:
On 8/29/2019 10:45 AM, Balázs Gibizer wrote:
As feature freeze is closing in I try to raise awareness of the implementation status of the support-move-ops-with-qos-ports <
; bp
[1].
Thanks for this since I know you've been pushing patches but I haven't been able to get myself past the hump that is [3] yet.
The original goal of the bp was to support every move operations (cold migrate, resize, live-migrate, evacuate, unshelve). Today I have ready and tested (unit + functional) patches proposed for cold migrate and resize [2]. I don't think every move operations will be ready and merged in Train but I still hope that there is a chance for cold migrate and resize to land. Sure I will continue working on supporting the operations that miss the Train in the U release.
This is probably OK since we agreed at the PTG that this blueprint was essentially going to be closing gaps in functionality introduced in Stein but not adding a new microversion, correct? If so, then doing it piece-meal seems OK to me.
Yeah, and it's already pretty clear about which specific operations can be done. I'm OK with having only a few operations done by Train given the API and the docs are correctly explaining which ones.
honestly once we have a functional move operation that make it much simpler to use this feature. so if we only land resize/cold migration that would still be a good step forward.
One possible complication in the current patch series is that it proposes the necessary RPC changes for _every_ move operations [3]. This might not be what we want to merge in Train if only cold migrate and resize support fill fit. So I see two possible way forwards: a) Others also feel that cold migrate and resize will fit into Train, and then I will quickly change [3] to only modify those RPCs. b) We agree to postpone the whole series to U. Then I will not spend too much time on reworking [3] in the Train timeframe.
Or (c) we just land that change. I was meaning to review that today anyway so this email is coincidental for me. I think passing the request spec down to the compute methods is fine and something we'll want to do eventually anyway for this series (even if the live migration stuff is deferred to U).
+1 FWIW, since 3 years I would like to pass the RequestSpec down to the compute but I hadn't time to do it yet. Cool with me.
i have had cases in the past where it would have been nice to have but i think this is a case where it makes sense as any other approch would be less clean.
A connected topic: I proposed patches [4] to add cold migrate and resize tempest coverage to the nova-grenade-multinode (renamed from nova-grenade-live-migrate) job as Matt pointed out in [3] that we don't have such coverage and that my original change in [3] would have broken a mixed-compute-version deployment.
I'm just waiting on CI results for those but since I've already been through them in some form and they are pretty small I think there is a good chance of landing these soon.
--
Thanks,
Matt
On 8/29/2019 11:09 AM, Matt Riedemann wrote:
One possible complication in the current patch series is that it proposes the necessary RPC changes for _every_ move operations [3]. This might not be what we want to merge in Train if only cold migrate and resize support fill fit. So I see two possible way forwards: a) Others also feel that cold migrate and resize will fit into Train, and then I will quickly change [3] to only modify those RPCs. b) We agree to postpone the whole series to U. Then I will not spend too much time on reworking [3] in the Train timeframe.
Or (c) we just land that change. I was meaning to review that today anyway so this email is coincidental for me. I think passing the request spec down to the compute methods is fine and something we'll want to do eventually anyway for this series (even if the live migration stuff is deferred to U).
I'm +2 on that change now.
A connected topic: I proposed patches [4] to add cold migrate and resize tempest coverage to the nova-grenade-multinode (renamed from nova-grenade-live-migrate) job as Matt pointed out in [3] that we don't have such coverage and that my original change in [3] would have broken a mixed-compute-version deployment.
I'm just waiting on CI results for those but since I've already been through them in some form and they are pretty small I think there is a good chance of landing these soon.
These CI changes are approved and I've rebased the series on top of them. -- Thanks, Matt
On Sat, Aug 31, 2019 at 12:06 AM, Matt Riedemann <mriedemos@gmail.com> wrote: On 8/29/2019 11:09 AM, Matt Riedemann wrote: One possible complication in the current patch series is that it proposes the necessary RPC changes for _every_ move operations [3]. This might not be what we want to merge in Train if only cold migrate and resize support fill fit. So I see two possible way forwards: a) Others also feel that cold migrate and resize will fit into Train, and then I will quickly change [3] to only modify those RPCs. b) We agree to postpone the whole series to U. Then I will not spend too much time on reworking [3] in the Train timeframe. Or (c) we just land that change. I was meaning to review that today anyway so this email is coincidental for me. I think passing the request spec down to the compute methods is fine and something we'll want to do eventually anyway for this series (even if the live migration stuff is deferred to U). I'm +2 on that change now. A connected topic: I proposed patches [4] to add cold migrate and resize tempest coverage to the nova-grenade-multinode (renamed from nova-grenade-live-migrate) job as Matt pointed out in [3] that we don't have such coverage and that my original change in [3] would have broken a mixed-compute-version deployment. I'm just waiting on CI results for those but since I've already been through them in some form and they are pretty small I think there is a good chance of landing these soon. These CI changes are approved and I've rebased the series on top of them. Thank you Matt! cheers, gibi -- Thanks, Matt
participants (4)
-
Balázs Gibizer
-
Matt Riedemann
-
Sean Mooney
-
Sylvain Bauza