yahoo-eng-team team mailing list archive

[Slawek Kaplonski <1903531@xxxxxxxxxxxxxxxxxx>]

** Changed in: neutron
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1903531

Title:
  Update of neutron-server breaks compatibility to previous neutron-
  agent version

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  During the update of Neutron from 15.1 to 15.3 (Train) server and
  agent are not compatible (RPC format) anymore.

  I was able to narrow down the issue to commit https://opendev.org/openstack/neutron/commit/00298fe6e84cd7610b39af50e9517885a182f47c or patchset https://review.opendev.org/#/c/744133/
  With this commit, fixing the security issue in bug https://bugs.launchpad.net/neutron/+bug/1867119 was addressed and a change to the RPC data structure now containing also the MAC address was required consequently back-ported to Train (https://bugs.launchpad.net/neutron/+bug/1867119/comments/6).

  This change breaks compatibility as the loop in method
  "_sanitize_addresses" (neutron/agent/linux/ipset_manager.py", line 47)
  does not handle this new format properly.

  --- 15.1 ---
  for ip in addresses:
              ip = netaddr.IPNetwork(ip)
              if ip.prefixlen == 0:
  --- /15.1 ---

  --- 15.3 ---
  for ip, _mac in addresses:
              ip = netaddr.IPNetwork(ip)
              if ip.prefixlen == 0:
  --- /15.3 ---

  As neutron server in version 15.1 delivers just a list of addresses,
  i,e. "['192.168.100.57', '192.168.100.160']", while after the update
  to 15.3 it sends a list of lists with each list element containing an
  IP as well a MAC address, i.e. "[['192.168.100.57', None],
  ['192.168.100.160', None]])" the code on the agent side has no way of
  handling both cases.

  According to
  https://docs.openstack.org/neutron/latest/contributor/internals/upgrade.html
  .... which states:

  "
  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).
  "

  an upgraded neutron-server should still work with the previous
  neutron-agent.

  I took the liberty to flag this as "security vulnerability" as
  security groups will likely not be applied / managed properly when
  running mixed between 15.1 and 15.3 which might be a common case in
  larger clusters.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1903531/+subscriptions