[nova][ptg] bumping compute RPC to 6.0
Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Do we want to bump the compute RPC to 6.0 in Victoria? We did not have the full view what we can gain[2] with such bump so Stephen and I searched through nova and collected the things we could clean up [1] eventually if we bump the compute RPC to 6.0 in Victoria. I can work on the RPC 6.0 patch during V and I think I can also help in with the possible cleanups later. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/compute-rpc-6.0 [2] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-16-16.00.log....
On Mon, May 25, 2020 at 11:58 AM Balázs Gibizer <balazs.gibizer@est.tech> wrote:
Hi,
[This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG]
Do we want to bump the compute RPC to 6.0 in Victoria?
Like it or not, fast-forward upgrades where one or more releases are skipped is something we have to live with and take into account. What would be the FFWD upgrade implications of bumping RPC to 6.0 in Victoria, specifically for someone upgrading from Train to W or later?
We did not have the full view what we can gain[2] with such bump so Stephen and I searched through nova and collected the things we could clean up [1] eventually if we bump the compute RPC to 6.0 in Victoria.
I can work on the RPC 6.0 patch during V and I think I can also help in with the possible cleanups later.
Cheers, gibi
[0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/compute-rpc-6.0 [2] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-16-16.00.log....
On Mon, May 25, 2020 at 11:58 AM Balázs Gibizer <balazs.gibizer@est.tech> wrote:
Hi,
[This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG]
Do we want to bump the compute RPC to 6.0 in Victoria?
Like it or not, fast-forward upgrades where one or more releases are skipped is something we have to live with and take into account. we should take them into account but that does not mean we should bend over backwards to make them work etiehr. depending on if you need a functional contolplane druing the FFU
On Mon, 2020-05-25 at 12:05 -0400, Artom Lifshitz wrote: the inmpact will be different. if a functional contol plane is required people will have to stop and bring all host up to 6.0 before unpinng and going to 6.X. i think that is reasonable even if that means FFU has to be done in two steps.
What would be the FFWD upgrade implications of bumping RPC to 6.0 in Victoria, specifically for someone upgrading from Train to W or later? im trying to remember off the top of my head but when we bump to 5.0, 5.0 was identical to 4.latest. it was reserved for compatiblity on upgades, you had to move all host to 5.0 before you could unping and moveing the contolplane to 5.X to preseve the ablity for the contoler to talk to the compute nodes.
this is the text for 4.0 ... Kilo supports messaging version 3.40. So, any changes to existing methods in 3.x after that point should be done so that they can handle the version_cap being set to 3.40 ... Version 4.0 is equivalent to 3.40. Kilo sends version 4.0 by default, can accept 3.x calls from Juno nodes, and can be pinned to 3.x for Juno compatibility. All new changes should go against 4.x. if we followed the patteren in https://github.com/openstack/nova/commit/ebfa09fa197a1d88d1b3ab1f308232c3df7... and https://github.com/openstack/nova/commit/5309120d7954da0b5ea67b0baf7c8d7ca24... victoria would send 6.0 by default and retain support for 5.11. but we would drop compatiblty for 5.x in 6.1. i dont think it's reasonable to require infinite FFU without any stop and an online contol plane. if you were upgrading from icehouse to ussuri today you would have to stop at kilo(4.0) and queens(5.0) due to rpc compatiablity, if you want the api/contol plane to be able to comunicate with the compute nodes during the upgrade. if we bump to 6.0 in vicoria that would become the next point were we have to stop. by stop i mean bring all the compute nodes to 6.0 before upgrading the contole plane past 6.0 that is 4-5 release of RPC compatibility between major version which is reasonable. if you dont require any control plane druing the FFU, you could stop all nova service on the contolers and compute node leaving the vms running and then jump all the nova code to W. you would have to run any db migration that were required but provide we had not online migration that required the compute agent to start then we should not have an FFU inpact. if we have an online update that required the compute agent to start, then provided we dont drop that compatiablity code before W we shoudl also be fine as we can run it there when everythin is on 6.x keeping reshapes or onine update untell the release you finish on is required for all FFUs unless you strop and run the code in the middle. so there is an impact on FFU but i don't necessarily think there is an inpact on how OOO does FFU since the control plane is down during the FFU. i think osa and kolla dont actully aim for FFU but instead aim for 0 downtime upgrades. 0 downtime upgrades at least was kolla-anisbles goal at one point so kolla ansible would have to stop at the RPC boundaries to achive skip level upgradews without control plane downtime. i may be totally wrong about this but i think that is how the RPC compatiblity is inteded to work. hopefully dan will correct me.
We did not have the full view what we can gain[2] with such bump so Stephen and I searched through nova and collected the things we could clean up [1] eventually if we bump the compute RPC to 6.0 in Victoria.
I can work on the RPC 6.0 patch during V and I think I can also help in with the possible cleanups later.
Cheers, gibi
[0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/compute-rpc-6.0 [2] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-16-16.00.log....
On Mon, May 25, 2020 at 12:05, Artom Lifshitz <alifshit@redhat.com> wrote:
On Mon, May 25, 2020 at 11:58 AM Balázs Gibizer <balazs.gibizer@est.tech> wrote:
Hi,
[This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG]
Do we want to bump the compute RPC to 6.0 in Victoria?
Like it or not, fast-forward upgrades where one or more releases are skipped is something we have to live with and take into account. What would be the FFWD upgrade implications of bumping RPC to 6.0 in Victoria, specifically for someone upgrading from Train to W or later?
My understanding is that during FFU you stop both the control plane and the compute services. If you need rolling upgrade of computes then you cannot do FFU but you have to roll forward one release at a time. Cheers, gibi
We did not have the full view what we can gain[2] with such bump so Stephen and I searched through nova and collected the things we could clean up [1] eventually if we bump the compute RPC to 6.0 in Victoria.
I can work on the RPC 6.0 patch during V and I think I can also help in with the possible cleanups later.
Cheers, gibi
[0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/compute-rpc-6.0 [2]
http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-16-16.00.log....
On Mon, May 25, 2020 at 17:54, Balázs Gibizer <balazs.gibizer@est.tech> wrote:
Hi,
[This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG]
Do we want to bump the compute RPC to 6.0 in Victoria?
We did not have the full view what we can gain[2] with such bump so Stephen and I searched through nova and collected the things we could clean up [1] eventually if we bump the compute RPC to 6.0 in Victoria.
I can work on the RPC 6.0 patch during V and I think I can also help in with the possible cleanups later.
On the PTG we agreed that gibi will try to propose a RPC 6.0 bump patch before M3 and we will make a decision at M3 if we merge it or not. Cheers, gibi
Cheers, gibi
[0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/compute-rpc-6.0 [2] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-16-16.00.log....
participants (3)
-
Artom Lifshitz
-
Balázs Gibizer
-
Sean Mooney