host_bind_override issues for br-vlan network provider

Bug #1814686 reported by Craig McIntyre
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack-Ansible
Fix Released
Undecided
James Denton

Bug Description

Environmental details:
Ubuntu Bionic (18.04)
Openstack release 18.1.3

Scenario:
Compute node and Network node have different physical interface configurations. Tenant networks exclusively vxlan so no requirement for "vlan" type provider on compute nodes.

In openstack_user_config.yml, the "vlan" type network provider config has a host_bind_override configured for a physical interface on the network node, as vlans will be used for provider networks here.

This configuration causes the linuxbridge-agent on the compute node to flap as the physical interface it is looking for does not exist.

As Netplan is in use, the veth bind to eth12 option is not avaialble.

Need to find a way to configure the host_bind_override on just the network nodes in a way that leaves the compute nodes with no br-vlan required.

Workaround:

Following discussions in #openstack-ansible it was suggested that a patch for a previous bug (Bug #1787462). Could potentially resolve this scenario.

In openstack_user_config.yml, the "vlan" type network provider config for br-vlan had "neutron_linuxbridge_agent" replaced with "network_hosts" in the group_binds: section and the os-neutron-install.yml was rerun.

    - network:
        container_bridge: "br-vlan"
        container_type: "veth"
        container_interface: "eth11"
        host_bind_override: "enp2s0f1"
        type: "vlan"
        range: "304:349"
        net_name: "physnet1"
        group_binds:
          - network_hosts

Outcome:

Network nodes inherit correct configuration and compute nodes do not, goal achieved.

Addendum:

Additional tests were performed to create a separate configuration for the "vlan" type network provider on compute hosts using the "compute_hosts" group_binds. As expected, this worked correctly, with the compute nodes inheriting different configuration to the network nodes.

Request for documentation to be updated with this new process as an alternative to requiring eth12 and veth bindings in ifupdown, and to provide a workable solution for netplan configurations in heterogeneous hardware environments.

Changed in openstack-ansible:
assignee: nobody → James Denton (james-denton)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to openstack-ansible (master)

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

Changed in openstack-ansible:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to openstack-ansible (master)

Reviewed: https://review.openstack.org/635013
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=df43c5119dec29fbb0dcec6d1d58dbbb85381c3b
Submitter: Zuul
Branch: master

commit df43c5119dec29fbb0dcec6d1d58dbbb85381c3b
Author: James Denton <email address hidden>
Date: Tue Feb 5 19:19:26 2019 +0000

    [docs] Apply provider network config on per-group basis

    This patch provides documentation for 'Provider Network Groups',
    aka 'the ability to define provider networks that are applied only to
    certain groups'. This allows deployers to configure provider networks
    across a heterogeneous environment as opposed to a homogeneous environment.
    It also updates the documentation by providing examples of single and
    multi-interface deployments.

    The docs call out the steps necessary to configure the
    openstack_user_config.yml file to configure provider networks
    on a per-group basis. Only groups listed under group_binds for a given
    provider network will utilize the given vars.

    Change-Id: I9611810722283a8a0e4c57e60576bd0c3506eacc
    Closes-Bug: 1814686

Changed in openstack-ansible:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/openstack-ansible 19.0.0.0b1

This issue was fixed in the openstack/openstack-ansible 19.0.0.0b1 development milestone.

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.