New interface hashing breaks upgrades for LinuxBridge

Bug #1504647 reported by Sean M. Collins
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
High
Sean M. Collins

Bug Description

Code introduced in https://review.openstack.org/#/c/224064/ touches code that did the interface name hashing. Let's ensure that it doesn't break upgrades.

IRC conversation:

http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2015-10-09.log.html#t2015-10-09T16:26:18

This bug is to fix upgrade, not fix the naming scheme.

Tags: linuxbridge
tags: added: linuxbridge
Changed in neutron:
importance: Undecided → High
status: New → Confirmed
milestone: none → mitaka-1
dql (duquanglong)
Changed in neutron:
assignee: nobody → dql (duquanglong)
dql (duquanglong)
Changed in neutron:
assignee: dql (duquanglong) → nobody
dql (duquanglong)
Changed in neutron:
assignee: nobody → dql (duquanglong)
Revision history for this message
Cedric Brandily (cbrandily) wrote :

The old algorithm doesn't hash interface names so it fails to generate valid interface names when:

  # len('%s.%s' % (physical_interface + vlan)) > 15
  len(physical_interface) > 14 - len(vlan)

The new algorithm hashs interface names (and generate different names) when:

  # large_vlan is a 4 digit vlan
  # len('%s.%s' % (physical_interface + large_vlan)) > 15
  # it's sadly not highlighted in https://review.openstack.org/#/c/224064/8/neutron/tests/unit/plugins/common/test_utils.py
  len(physical_interface) > 10

It means that old/new algorithms generate valid but different interface names when:

  10 < len(physical_interface) <= 14 - len(vlan) # implies vlan < 1000

So they behave differently when old algorithm generate valid names only for a subset of all vlans

Changed in neutron:
assignee: dql (duquanglong) → nobody
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/233715

Changed in neutron:
assignee: nobody → Sean M. Collins (scollins)
status: Confirmed → In Progress
Revision history for this message
Andreas Scheuring (andreas-scheuring) wrote : Re: Ensure new interface hashing does not break upgrades

uff. Good point. I haven't spent much thoughts about upgrade compatibility - sorry for that! And thanks for finding this!!
Let's roll it back and discuss how to solve the issue!

Revision history for this message
Andreas Scheuring (andreas-scheuring) wrote :

looks like we have to live with the fact that when you have a long device name like "abcdefghijklm", vlan devices will be named

abcdefghijklm.1
abcde<hash>.111

This is the only way to stay backwards compatible. It's not very nice for debugging - but I don't see any other feasible solution.

Any ideas?

summary: - Ensure new interface hashing does not break upgrades
+ New interface hashing breaks upgrades for LinuxBridge
description: updated
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/233715
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=e7488570e70d0a92cc3d8fa3b5853df7fbb33564
Submitter: Jenkins
Branch: master

commit e7488570e70d0a92cc3d8fa3b5853df7fbb33564
Author: Sean M. Collins <email address hidden>
Date: Mon Oct 12 12:43:02 2015 -0400

    Revert "Make OVS interface name hashing algorithm common and extend it"

    Based on discussion with Ihar and Cedric, this may break upgrades. Let's
    revert it for the time being and reassess.

    This reverts commit 3d0db13370eee09aaee5923c54d0e3188509c4e5.

    Change-Id: I69d74befb08e074c1bccd823cca0899de6ed57d6
    Closes-Bug: 1504647

Changed in neutron:
status: In Progress → Fix Committed
Revision history for this message
Thierry Carrez (ttx) wrote : Fix included in openstack/neutron 8.0.0.0b1

This issue was fixed in the openstack/neutron 8.0.0.0b1 development milestone.

Changed in neutron:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.