Documentation: Allow operators to provision multiple physical networks

[OpenStack Infra]

https://review.openstack.org/373455
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
Your project "openstack/kolla" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to.

commit d1673ad173ea96c0e018946f54caa99776855cc1
Author: Paul Bourke <email address hidden>
Date: Tue Sep 20 17:07:55 2016 +0100

    Allow operators to provision multiple physical networks

    Currently Kolla operators are restricted to configuring one physical
    network (physnet1).

    This change along with ml2_conf.ini augmentation can be used to setup
    multiple physical networks in openvswitch.

    E.g. To configure two physical networks, physnet1 and physnet2, with
    ports eth1 and eth2 associated respectively:

    In /etc/kolla/globals.yml, set

    neutron_bridge_name: "br-ex,br-ex2"
    neutron_external_interface: "eth1,eth2"

    In /etc/kolla/config/neutron/ml2_conf.ini

    [ovs]
    bridge_mappings = physnet1:br-ex,physnet2:br-ex2

    Co-Authored-By: Mick Thompson <email address hidden>
    Closes-Bug: #1625700
    DocImpact

    Change-Id: I9454ca98d9b058368129123109ccc56f95519874

[Chris L (onyx4)]

Is there a way currently to manually do this?

For example can I create the br-ex2 bridge manually in the OVS container on each compute and controller and add the port for eth2 ?

Then use the /etc/kolla/config to propagate the changes that you described.

Will the OVS changes be permanent or we would need a way to re-create the br-ex2 after a restart?

I already have SRIOV working on my setup for internal networks with VLAN tagging (segmentation ID), but I'm trying to find a way for hosts on virtIO to get on the same network using VLAN provider but on an internal interface instead of the external bridge interface used for Internet access.

Thanks,
Christian

[Mark Goddard (mgoddard)]

If you add this to globals.yml:

neutron_bridge_name: "br-ex,br-ex2"
neutron_external_interface: "eth1,eth2"

Then all you need to do is ensure that eth1 and eth2 exist. Kolla ansible will handle creating the br-ex and br-ex2 bridges and plugging eth1 and eth2 into them.

[Chris L (onyx4)]

Thanks for your response, I will try that right away.

If an interface is used for SRIOV with many VF created, can we use the PF itself for VirtIO for VLAN based provider network, or would I need to create a veth pair and put the PF into a linux bridge along with one of the veth since OVS takes over the whole port. I'm trying to not have to use another physical port if possible that I could share for SRIOV VF and VirtIO based VLAN provider network.

Some of my compute nodes have ens3 or ens1, I assume this cannot be a bridge interface since it will be taken over by OVS for Neutron, how do we map to different interfaces for different compute hosts again?

Thanks,
Christian

[Mark Goddard (mgoddard)]

I'm not sure about using the PF - you would need to test this. If it does not work, could you use a VF instead?

If I need to use the same network for non-neutron traffic (e.g. a control plane VLAN), I typically use the method you described - create a bridge with a veth pair between it and OVS. Kayobe (which uses kolla ansible) provides automation for this. More info here: http://kayobe.readthedocs.io/en/latest/configuration/network.html#neutron-networking.

If you have different interfaces on different hosts, use host_vars or group_vars instead of globals.yml to define the variable.

[David Rabel (rabel-b1)]

Am I right, that this feature has been implemented two years ago and this bug report is only for the documentation?

[Adam Heczko (aheczko-mirantis)]

Release notes exists though the documentation part is still lacking.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/kolla-ansible/+/813965

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/kolla-ansible/+/813965
Committed: https://opendev.org/openstack/kolla-ansible/commit/f7403cf4f27acacbec16d7dc09faaab5df3db568
Submitter: "Zuul (22348)"
Branch: master

commit f7403cf4f27acacbec16d7dc09faaab5df3db568
Author: Mark Goddard <email address hidden>
Date: Thu Oct 14 09:54:05 2021 +0100

    docs: Improve info about neutron external interface

    Change-Id: I3a9c49c73a932b3d5ceed65c92190e5d72e27bbb
    Closes-Bug: #1626259

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/xena
Review: https://review.opendev.org/c/openstack/kolla-ansible/+/814766

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/kolla-ansible/+/814767

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/kolla-ansible/+/814767
Committed: https://opendev.org/openstack/kolla-ansible/commit/a61d4e721550460e9d3b79454c7cf4807e2287fb
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit a61d4e721550460e9d3b79454c7cf4807e2287fb
Author: Mark Goddard <email address hidden>
Date: Thu Oct 14 09:54:05 2021 +0100

    docs: Improve info about neutron external interface

    Change-Id: I3a9c49c73a932b3d5ceed65c92190e5d72e27bbb
    Closes-Bug: #1626259

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/kolla-ansible/+/814766
Committed: https://opendev.org/openstack/kolla-ansible/commit/2d69bdc8aed021e67bc6c7c83d71e6b30e80dcd9
Submitter: "Zuul (22348)"
Branch: stable/xena

commit 2d69bdc8aed021e67bc6c7c83d71e6b30e80dcd9
Author: Mark Goddard <email address hidden>
Date: Thu Oct 14 09:54:05 2021 +0100

    docs: Improve info about neutron external interface

    Change-Id: I3a9c49c73a932b3d5ceed65c92190e5d72e27bbb
    Closes-Bug: #1626259

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/kolla-ansible 13.0.0.0rc2 release candidate.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/kolla-ansible 12.3.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/kolla-ansible 14.0.0.0rc1 release candidate.