77fe5922bd
The patch adds an OVS extra parameter to delete controller for bridges
configured with standalone fail mode. By default, bridges are created
without having an openflow controllers. If node is restarted, the bridge
is set to standalone mode but if a service managing the bridge sets a
controller, it will remain in the ovsdb.
As ovs-vswitchd sets the bridge behavior to normal MAC learning switch
only if bridge in standalone mode can't communicate with its controller,
leaving controller defined can cause node outage when bridge is used as
management network. In such case controller service, like
neutron-openvswitch-agent, would need to communicate over management
network but given that bridge is in standalone mode but communicates
with controller, management network won't be reachable. This creates a
chicken-egg problem.
By removing controller by default, ovs-vswitchd implements a normal
action rule to the standalone bridge and service can use the bridge as
management network and eventually set the brdige to secure and set the
flows manually.
See opened Bugzilla for more information:
https://bugzilla.redhat.com/show_bug.cgi?id=1473763
Closes-bug: #1712517
Change-Id: Iad48312667834ea8f5c7145595ae89cb5159b36d
(cherry picked from commit
|
||
|---|---|---|
| doc/source | ||
| etc/os-net-config/samples | ||
| os_net_config | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| babel.cfg | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Team and repository tags
os-net-config
host network configuration tool
An implementation of the 'network configuration' spec @ https://review.openstack.org/#/c/97859/. The intention is for this code to be moved under the tripleo project in due course.
- Free software: Apache license
- Source: http://git.openstack.org/cgit/openstack/os-net-config
- Bugs: http://bugs.launchpad.net/os-net-config
Features
The core aim of this project is to allow fine grained (but extendable) configuration of the networking parameters for a network host. The project consists of:
- A CLI (os-net-config) which provides configuration via a YAML or JSON file formats. By default os-net-config uses a YAML config file located at /etc/os-net-config/config.yaml. This can be customized via the --config-file CLI option.
- A python library which provides configuration via an object model.
YAML Config Examples
- Configure an OVS bridge with a single attached interface (port)
network_config:
-
type: ovs_bridge
name: br-ctlplane
use_dhcp: true
ovs_extra:
- br-set-external-id br-ctlplane bridge-id br-ctlplane
members:
-
type: interface
name: em1
- Configure an OVS bridge on top of an OVS bond
network_config:
-
type: ovs_bridge
name: br-ctlplane
use_dhcp: true
members:
-
type: ovs_bond
name: bond1
members:
-
type: interface
name: em1
-
type: interface
name: em2
- Configure a tagged VLAN interface on top of an OVS bridge
network_config:
-
type: ovs_bridge
name: br-ctlplane
use_dhcp: true
members:
-
type: interface
name: em1
-
type: vlan
vlan_id: 16
addresses:
-
ip_netmask: 192.0.2.1/24Provider Configuration
Providers are use to apply (implement) the desired configuration on the host system. By default 3 providers are implemented:
- Ifcfg: persistent network config format stored in /etc/sysconfig/network-scripts
- ENI: persistent network config format stored in /etc/network/interfaces
- iproute2: non-persistent provider which implements the config using iproute2, vconfig, etc... (implementation in progress)
When using bin/os-net-config the provider is automatically selected based on the host systems perferred persistent network type (ifcfg or ENI). This can be customized via the --provider CLI option.