If the Neutron backend makes use of Neutron agents, the Neutron server have backwards compatibility code to deal with older messaging payloads.
isolating a single service that accesses database (neutron-server).
To simplify the matter, it’s always assumed that the order of service upgrades is as following:
first, all neutron-servers are upgraded.
then, if applicable, neutron agents are upgraded.
This approach allows us to avoid backwards compatibility code on agent side and is in line with other OpenStack projects that support rolling upgrades (specifically, nova).
"
@LIU Yulong I accept your opinion, but this is not how things are designed and documented or would even work for larger environments:
If I may quote myself (initial post):
--- /docs.openstack .org/neutron/ latest/ contributor/ internals/ upgrade. html .... which states:
According to https:/
"
Those requirements are achieved in Neutron by:
If the Neutron backend makes use of Neutron agents, the Neutron server have backwards compatibility code to deal with older messaging payloads.
isolating a single service that accesses database (neutron-server).
To simplify the matter, it’s always assumed that the order of service upgrades is as following:
first, all neutron-servers are upgraded.
then, if applicable, neutron agents are upgraded.
This approach allows us to avoid backwards compatibility code on agent side and is in line with other OpenStack projects that support rolling upgrades (specifically, nova).
"
---