As Felipe pointed out, the compatibility layer relies on the server side. But making a stable upgrade should not trigger this problem of course.
The mentioned patch [1] complies with the OVO versioning rules, allowing version downgrade (in the server side).
Is there an order in the upgrade procedure you used? According to "Rolling upgrade" section in [2]:
"""
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.
"""
Hello:
As Felipe pointed out, the compatibility layer relies on the server side. But making a stable upgrade should not trigger this problem of course.
The mentioned patch [1] complies with the OVO versioning rules, allowing version downgrade (in the server side).
Is there an order in the upgrade procedure you used? According to "Rolling upgrade" section in [2]:
"""
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.
"""
Regards.
[1] https:/ /github. com/openstack/ neutron/ commit/ b452c508b62 /github. com/openstack/ neutron/ blob/master/ doc/source/ contributor/ internals/ upgrade. rst
[2] https:/