Juju Charm - Open Virtual Network - Dedicated Software Gateway
Go to file
Frode Nordahl e64a527e23
Work-around for Cargo download dependency failed
This is a work-around for charm build failures resulting in:
"Cargo download dependency failed "send: no filter connected".

This is documented in the following upstream issue:
https://github.com/rust-lang/cargo/issues/12202

This affects lunar builds where the curl version is 7.88.1.

Thanks to Colin Watson for help with figuring this out.

Closes-Bug: #2037589
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I7a01c7cf9e28d1b766d45b2dcc906d44b347b1d7
2023-10-11 11:21:14 +02:00
src Merge "Add 2023.2 Bobcat support" 2023-08-04 21:40:11 +00:00
unit_tests Implementation of deferred restarts 2021-04-09 19:46:41 +00:00
.gitignore Use Netplan to configure SR-IOV and HWOL 2022-04-04 09:43:32 +02:00
.gitreview Consume chassis code from layer-ovn 2019-11-20 09:57:56 +01:00
.stestr.conf Initial commit 2019-10-10 16:38:52 +02:00
.travis.yml Initial commit 2019-10-10 16:38:52 +02:00
.zuul.yaml Add Antelope support 2023-04-26 12:37:07 +00:00
README.md Consume chassis code from layer-ovn 2019-11-20 09:57:56 +01:00
bindep.txt Add Kinetic and Zed support 2022-09-20 18:36:45 +03:00
charmcraft.yaml Work-around for Cargo download dependency failed 2023-10-11 11:21:14 +02:00
metadata.yaml Update to build using charmcraft 2022-02-01 21:04:37 +00:00
osci.yaml Add 2023.2 Bobcat support 2023-08-03 13:56:36 -04:00
rebuild Make version pinning optional 2023-08-22 15:13:27 +02:00
rename.sh Update to build using charmcraft 2022-02-01 21:04:37 +00:00
requirements.txt Add Kinetic and Zed support 2022-09-20 18:36:45 +03:00
test-requirements.txt Add Kinetic and Zed support 2022-09-20 18:36:45 +03:00
tox.ini tox.ini: Fixup 2023-01-04 23:37:10 +01:00

README.md

Overview

The ovn-dedicated-chassis charm provides the Open Virtual Network (OVN) local controller, Open vSwitch Database and Switch. It is used in conjunction with the ovn-central charm.

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

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

The ovn-dedicated-chassis charm is a principle charm that sets up a software gateway on a dedicated host. Alternatively, the subordinate ovn-chassis charm can be used.

Note: The OVN charms are supported starting with OpenStack Train.

Usage

The OpenStack Base bundle gives an example of how you can deploy OpenStack and OVN with Vault to automate certificate lifecycle management.

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

Refer to Open Virtual Network (OVN) in the OpenStack Charms Deployment Guide for details, including deployment steps.

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.

Network spaces

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-dedicated-chassis --bind "ovsdb=internal-space"

By binding the data extra-binding you can influence which interface will be used for overlay traffic.

juju deploy ovn-dedicated-chassis --bind "data=overlay-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 (bridge-interface-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 interfacing 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.

Deferred service events

Operational or maintenance procedures applied to a cloud often lead to the restarting of various OpenStack services and/or the calling of certain charm hooks. Although normal, such events can be undesirable due to the service interruptions they can cause.

The deferred service events feature provides the operator the choice of preventing these service restarts and hook calls from occurring, which can then be resolved at a more opportune time.

See the Deferred service events page in the OpenStack Charms Deployment Guide for an in-depth treatment of this feature.

Bugs

Please report bugs on Launchpad.

For general questions please refer to the OpenStack Charm Guide.