Ussuri-only: Network segments are not tried out for allocation

Bug #1940312 reported by Thiago Paiva Brito
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
Unassigned

Bug Description

* High level description: When we get a list of segments to choose from, and the first segment is already allocated, it fails right away returning RetryRequest exception, the the other segments are never tried out.

I explain it a little further on the comments of PatchSet 1 here: https://review.opendev.org/c/openstack/neutron/+/803986/1

This actually works at master due to a side effect of a refactoring that was done on https://opendev.org/openstack/neutron/commit/6eaa6d83d7c7f07fd4bf04879c91582de504eff4 to randomize the selection of segments, but on stable/ussuri, when not specifying the provider_network_type, we got into a situation where we had segments to allocate in vlan but neutron was allocating vxlan instead.

* Pre-conditions: network_segment_range plugin enabled and several vlan project networks created on the system

* Step-by-step reproduction steps: openstack --os-username 'project1_admin' --os-password '******' --os-project-name project1 --os-auth-url http://keystone.openstack.svc.cluster.local/v3 --os-user-domain-name Default --os-project-domain-name Default --os-identity-api-version 3 --os-interface internal --os-region-name RegionOne network create network11

* Expected output: network created successfully (there was available ranges)

* Actual output: HttpException: 503, Unable to create the network. No tenant network is available for allocation.

* Version:
  ** OpenStack version: stable/ussuri
  ** Linux distro: Centos 7
  ** Deployment: StarlingX Openstack

* Perceived severity: Major - System is usable in some circumstances

description: updated
Revision history for this message
Slawek Kaplonski (slaweq) wrote :

You said it is fixed in master by https://review.opendev.org/c/openstack/neutron/+/783639 but that patch is only in stable/Wallaby and master. So I think that the same issue is also in Victoria, right?

Changed in neutron:
importance: Undecided → Medium
assignee: nobody → Thiago Paiva Brito (outbrito)
Revision history for this message
Slawek Kaplonski (slaweq) wrote : auto-abandon-script

This bug has had a related patch abandoned and has been automatically un-assigned due to inactivity. Please re-assign yourself if you are continuing work or adjust the state as appropriate if it is no longer valid.

Changed in neutron:
assignee: Thiago Paiva Brito (outbrito) → nobody
tags: added: timeout-abandon
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (stable/ussuri)

Change abandoned by "Slawek Kaplonski <email address hidden>" on branch: stable/ussuri
Review: https://review.opendev.org/c/openstack/neutron/+/803986
Reason: This review is > 4 weeks without comment, and failed Zuul jobs the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Revision history for this message
Thiago Paiva Brito (outbrito) wrote :

In fact, the patches that fix that problem (although as a side effect) were already cherry-picked and merged on the stable branches:

train: https://review.opendev.org/c/openstack/neutron/+/808160
ussuri: https://review.opendev.org/c/openstack/neutron/+/804999
victoria: https://review.opendev.org/c/openstack/neutron/+/805000
wallaby: https://review.opendev.org/c/openstack/neutron/+/783639

Thanks Slawek and Rodolfo for those.

Changed in neutron:
status: New → Fix Committed
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.