ovn chassis #0

Supports: bionic eoan
Add to new model

Description

Subordinate charm that deploys the OVN local controller and Open vSwitch
Database and Switch.


Overview

This charm provides the Open Virtual Network (OVN) local controller, Open
vSwitch Database and Switch.

On successful deployment the unit will be enlisted as a Chassis in the OVN
network.

Open vSwitch bridges for integration, external Layer2 and Layer3 connectivity
is managed by the charm.

Note: The OVN charms are considered preview charms.

Usage

OVN makes use of Public Key Infrastructure (PKI) to authenticate and authorize
control plane communication. The charm requires a Certificate Authority to be
present in the model as represented by the certificates relation.

There is a OVN overlay bundle
for use in conjunction with the OpenStack Base bundle
which give an example of how you can automate certificate lifecycle management
with the help from Vault.

Network Spaces support

This charm supports the use of Juju Network Spaces.

By binding the ovsdb endpoint you can influence which interface will be used
for communication with the OVN Southbound DB as well as overlay traffic.

juju deploy ovn-chassis --bind "ovsdb=data-space"

Port Configuration

Chassis port configuration is composed of a mapping between physical network
names to bridge names (ovn-bridge-mappings) and individual interface to
bridge names (interface-bridge-mappings). There must be a match in both
configuration options before the charm will configure bridge and interfaces on
a unit.

The physical network name can be referenced when the administrator programs the
OVN logical flows, either by talking directly to the Northbound database, or by
interfaceing with a Cloud Management System (CMS).

Networks for use with external Layer3 connectivity should have mappings on
chassis located in the vicinity of the datacenter border gateways. Having two
or more chassis with mappings for a Layer3 network will have OVN automatically
configure highly available routers with liveness detection provided by the
Bidirectional Forwarding Detection (BFD) protocol.

Chassis without direct external mapping to a external Layer3 network will
forward traffic through a tunnel to one of the chassis acting as a gateway for
that network.

Note: It is not necessary nor recommended to add mapping for external
Layer3 networks to all chassis. Doing so will create a scaling problem at
the physical network layer that needs to be resolved with globally shared
Layer2 (does not scale) or tunneling at the top-of-rack switch layer (adds
complexity) and is generally not a recommended configuration.

Networks for use with external Layer2 connectivity should have mappings present
on all chassis with potential to host the consuming payload.

Bugs

Please report bugs on Launchpad.

For general questions please refer to the OpenStack Charm Guide.


Configuration

bridge-interface-mappings
(string) A space-delimited list of key-value pairs that map a network interface MAC address or name to a local ovs bridge to which it should be connected. Note: MAC addresses of physical interfaces that belong to a bond will be resolved to the bond name and the bond will be added to the ovs bridge. Bridges referenced here must be mentioned in the `ovn-bridge-mappings` configuration option. If a match is found the bridge will be created if it does not already exist, the matched interface will be added to it and the mapping found in `ovn-bridge-mappings` will be added to the local OVSDB under the `external_ids:ovn-bridge-mappings` key in the Open_vSwitch table. An example value mapping two network interface mac address to two ovs bridges would be: br-internet:00:00:5e:00:00:42 br-provider:enp3s0f0 Note: OVN gives you distributed East/West and highly available North/South routing by default. You do not need to add provider networks for use with external Layer3 connectivity to all chassis. Doing so will create a scaling problem at the physical network layer that needs to be resolved with globally shared Layer2 (does not scale) or tunneling at the top-of-rack switch layer (adds complexity) and is generally not a recommended configuration. Add provider networks for use with external Layer3 connectivity to individual chassis located near the datacenter border gateways by adding the MAC address of the physical interfaces of those units.
ovn-bridge-mappings
(string) A space-delimited list of key-value pairs that map a physical network name to a local ovs bridge that provides connectivity to that network. The physical network name can be referenced when the administrator programs the OVN logical flows either by talking directly to the Northbound database or by interfacing with a Cloud Management System (CMS). Each charm unit will evaluate each key-value pair and determine if the configuration is relevant for the host it is running on based on matches found in the `bridge-interface-mappings` configuration option. If a match is found the bridge will be created if it does not already exist, the matched interface will be added to it and the mapping will be added to the local OVSDB under the `external_ids:ovn-bridge-mappings` key in the Open_vSwitch table. An example value mapping two physical network names to two ovs bridges would be: physnet1:br-internet physnet2:br-provider NOTE: Values in this configuration option will only have effect for units that have a interface referenced in the `bridge-interface-mappings` configuration option.