search

F5Networks / f5-openstack-lbaasv2-driver

F5 LBaaSv2 service provider driver for OpenStack Liberty and beyond
http://clouddocs.f5.com/products/openstack/lbaasv2-driver/master/
Apache License 2.0
21 stars 37 forks source link

Service building for member should map neutron port when port is available #601

Closed pjbreaux closed 7 years ago

pjbreaux commented 7 years ago

OpenStack Release

liberty and merging forward

Bug Severity

Issue is on unreleased driver code.

For bugs enter the bug severity level. Do not set any labels.

Severity: <Fill in level: 1 through 5>

Severity level definitions:

  1. Severity 1 (Critical) : Defect is causing systems to be offline and/or nonfunctional. immediate attention is required.
  2. Severity 2 (High) : Defect is causing major obstruction of system operations.
  3. Severity 3 (Medium) : Defect is causing intermittent errors in system operations.
  4. Severity 4 (Low) : Defect is causing infrequent interuptions in system operations.
  5. Severity 5 (Trival) : Defect is not causing any interuptions to system operations, but none-the-less is a bug.

Description

When the logic to create neutron ports for pool members was removed from the driver, the logic to actually include a port for the member when that port exists was also removed. However, this was producing a failure of two neutron lbaas tests due to fdb entry creation expecting the 'port' key to exist in the member. It didn't, so the member provisioning status was set to ERROR. That should have prompted us to look at the driver code again, ensuring that the port was set in the service object before continuing. But we did not have that test, or the right test did not have the proper assertion.

This change is to add the port key back to the member and write tests to ensure this is the case. I will include the unit tests here on this issue, and @szakeri will include a tempest test for this code change.

@swormke @dflanigan

pjbreaux commented 7 years ago

@jlongstaf ---^

zancas commented 7 years ago

We all looked at this (including @dflanigan ) and decided that since the code that fixes the issue is in master, this issue should be closed. We hypothesize that the reason it did not auto-close because there were "Fixes #601" references in 2 different Pull Requests.