Flat provider network can only be 'public'

[ChenjieXu]

Title
-----
Flat provider network can only be 'public'

Brief Description
-----------------
Flat provider network can only be 'public'. If you try to create a flat provider network with name 'providernet-a', the following error will be reported: "Invalid input for operation: physical_network 'providernet-a' unknown for flat provider network."

Severity
--------
Critical

Steps to Reproduce
------------------
1. On the active controller:
   source /etc/platform/openrc
   system host-lock compute-0
   ssytem host-lock compute-1
   system datanetwork-add providernet-a flat
   system host-if-list -a compute-0
   system host-if-list -a compute-1
   system host-if-modify -m 1500 -n data0 -d providernet-a -c data compute-0 ${DATA0IFUUID}
   system host-if-modify -m 1500 -n data0 -d providernet-a -c data compute-1 ${DATA0IFUUID}
   system host-unlock compute-0
   system host-unlock compute-1

2. After compute-0 and compute-1 rebooting and become available, on the active controller:
   export OS_CLOUD=openstack_helm
   neutron net-create --provider:network_type=flat --provider:physical_network=providernet-a --router:external external-net

Expected Behavior
------------------
Flat network external-net can be created.

Actual Behavior
----------------
Flat network external-net can't be created.

System Configuration
--------------------
System mode: Standard 2+2 on Bare metals

Reproducibility
---------------
100%

Branch/Pull Time/Commit
-----------------------
0306 ISO Image built for OVS DPDK Upgrade

Timestamp/Logs
--------------
controller-0:~$ neutron net-create --provider:network_type=flat --provider:physical_network=providernet-a --router:external external-net
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Invalid input for operation: physical_network 'providernet-a' unknown for flat provider network.
Neutron server returns request_ids: ['req-ac2f998a-fd05-4722-8349-121a4cb69ef7']

Last time install passed
------------------------
n/a

[ChenjieXu (midone)]

The flat network is configured as 'public' in ovs agent's config file ml2_conf.ini:
   [ml2_type_flat]
   flat_networks = public

Creating flat provider network 'providernet-a' can't change the configuration.

You can check the configuration by following command on the active controller:
   export OS_CLOUD=openstack_helm
   kubectl -n openstack get pod | grep neutron
   kubectl -n openstack exec -it ${neutron-ovs-agent} bash
   cd /etc/neutron/plugins/ml2/
   cat ml2_conf.ini

[Matt Peters (mpeters-wrs)]

The latest STX neutron docker images contain the network segment range feature that would not use the configuration file for managing the physical networks. Therefore the physical network would first need to be configured as a network segment range with just the physical network name for flat networks. The values in the configuration file will be ignored.

[cheng li (chengli3)]

Matt, we create segment range for *flat* network?

[ChenjieXu (midone)]

I tried on my environment with following command:

ADMINID=`openstack project list | grep admin | awk '{print $2}'`
openstack network segment range create provider-flat --network-type flat --physical-network providernet-a --project ${ADMINID}

However following error occured. It seems that we can't create a flat network segment range? Or maybe I use an old docker image?
openstack network segment range create: error: argument --network-type: invalid choice: u'flat' (choose from 'geneve', 'gre', 'vlan', 'vxlan')

The docker image for stx-neutron:
192.168.204.2:9001/starlingx/stx-neutron dev-centos-master-latest 39c78d818a77 2 weeks ago 699MB

[Matt Peters (mpeters-wrs)]

Sorry, you are correct, flat networks are not handled by the neutron configuration (that was an old behavior).

This is indeed a bug in StarlingX. It should be populating the flat_networks parameter with the configured flat data networks.

[Ghada Khalil (gkhalil)]

Marking as release gating. Confirmed to be a starlingx bug. The fix is to populate a helm override from the configured data networks

[Ricardo Perez (richomx)]

Using the current infrastructure @ GDC and following the steps described in this bug, i'm able to reproduce it in a 2+2 Bare Metal.

"Invalid input for operation: physical_network 'providernet-a' unknown for flat provider network."

However, checking the host interfaces, you'll see something like:

data0 | data | ethernet | None | [u'enp175s0f0'] | [] | [] | MTU=1500,accelerated=True | [u'providernet-a']

[cheng li (chengli3)]

I can think of two options for this issue.

The network name limitation of 'public' is introduced by armada manifest[1].
So the first approach could be removing this "public" from armada manifest, to use the default "*" in values.yaml.

The second approach is the way mentioned by Ghada, to populate a helm override from the configured data networks.

[1] https://github.com/openstack/stx-config/blob/bc7f16ca7cd4eb199590cecd4d07215097de7823/kubernetes/applications/stx-openstack/stx-openstack-helm/stx-openstack-helm/manifests/manifest.yaml#L974

[Matt Peters (mpeters-wrs)]

The manifest can be updated to remove 'public', but it should not be replaced by '*' since that will permit any physical name to be used. In StarlingX we explicitly configure and manage data networks, therefore the manifest should be set to an empty value and the Helm override should be populated based on the configured 'flat' data networks.

[cheng li (chengli3)]

It makes sense, I can do that

[Juan Pablo Gomez (jpgomez)]

This issue was also reproduced in Duplex bare metal

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/649237
Committed: https://git.openstack.org/cgit/starlingx/config/commit/?id=2ac4831c66d188666fbb46681085e8bdad37f486
Submitter: Zuul
Branch: master

commit 2ac4831c66d188666fbb46681085e8bdad37f486
Author: chengli3 <email address hidden>
Date: Tue Apr 2 14:42:34 2019 +0800

    Populate flat networks in ml2 configuration

    'flat_networks' should be configured to specify which physical network
    can be used as flat network. This patch is to populate'flat_network'
    based on sysinv.

    Change-Id: I2cec1e1234976b9d73ce4be74527a5bcbb7bc5eb
    Closes-bug: #1821150
    Signed-off-by: chengli3 <email address hidden>