Open Stack

On Mon, 2020-05-25 at 12:05 -0400, Artom Lifshitz wrote:
> On Mon, May 25, 2020 at 11:58 AM Balázs Gibizer <balazs.gibizer at 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
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/ebfa09fa197a1d88d1b3ab1f308232c3df7dc009
and https://github.com/openstack/nova/commit/5309120d7954da0b5ea67b0baf7c8d7ca24b8480

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.html#l-103
> > 
> > 
> > 
> 
>