VRRP healthchecks were enabled by default starting in the 19.07 charm
release for network deployments which utilize l3ha or dvr+snat. The VRRP
healthchecks have specific expectations that may not be satisfied in
various data centers. This leads to problems with networks as failed
healthchecks lead to router failovers.
This change alters the default config option to disable the vrrp
healthchecks by default and require users to opt in to using them. The
description around the option has been updated to indicate that doing so
may lead to routers failing over if ICMP pings are missed.
Change-Id: Ie281a311a95ba394d72c2dfeeb0a1a0a12847e77
Closes-Bug: #192101
Update docs to clarify that manual removing of previous
values are required if the config changes.
Related-bug: #1915967
Change-Id: I99ffab5488a088c40c276ba5be0b60223e077eb6
Replace in-charm SR-IOV code with the common ``SRIOVContext``
Do not do run-time configuration of SR-IOV or hardware adaption
for hardware offload. In addition to being detrimental to any
virtual machine instance consuming the VF this will break NIC
firmware in some configurations.
The task is delegated to the installed packages and their systemd
services and configuration will occur at system bootup time.
We may consider adding an action to perform the configuration at
run-time if the operator really wants to, but it is very
complicated to get right. For example if you are using bonding
and hardware offload the virtual functions and hardware specific
setup has to happen _BEFORE_ netplan applies network configuration
to the system.
Closes-Bug: #1908351
Change-Id: Id0b81848658a3bd34470440bd68928ae9f6682e4
By default, mlockall() is enabled for ovs-vswitchd. This results in
locking all of ovs-vswitchd's process memory into physical RAM and
prevents paging. This enables network performance but can lead to
memory exhaustion in memory-constrained environments. To disable
mlockall(), the disable-mlockall charm config option can be set to
True. If unset, disable-mlockall charm config will result in
disabling mlockall if running in a container.
The drop_config.append(OVS_DEFAULT) logic is no longer used as
it prevents a rewrite of the config template when charm config is
reset. For example, the new behavior results in
/etc/default/openvswitch-switch being written with comments only
when the corresponding config options are disabled (see template),
resulting in openvswitch-switch being restarted.
Due to the removal of drop_config.append(OVS_DEFAULT), pause/resume
actions need to explicitly remove openswitch-switch to maintain
prior behavior for non-DPDK deployments. In other words, pause/resume
will not restart openvswitch-switch.
Closes-Bug: #1906280
Related-Bug: #1908615
Change-Id: I2e3153e90c7a4a1b7dec7d6df427b33a449f414d
This patch adds support for setting of-inactivity-probe in
/etc/neutron/plugins/ml2/openvswitch_agent.ini
[ovs]
of_inactivity_probe = 10
Change-Id: Idb3ab6b0e82200226e3063065192b4346d0c5206
Closes-Bug: 1852582
Defaults to 30s (i.e. enabled) but also allows disabling
healthchecks by setting to 0.
Change-Id: I5bb7d362f0d957237e24f79f1f82583661bed470
Closes-Bug: #1890900
Enable support for use of hardware offload via OVS; this requires
OpenStack Stein or later in conjunction with the latest HWE kernel
for Ubuntu 18.04 LTS.
Change-Id: I4ce47b1712e79bfbed9ac708cc521840b3709724
Refactor SR-IOV VF configuration support to use sriov-netplan-shim
to configure VF's on PF's so the charm simply writes out the required
interfaces.yaml file and restarts the sriov-netplan-shim service
which is fully idempotent.
Change-Id: I7a3ddf91d4b2ae6aa0806d97c45b59e8a951f67f
This was originally fixed in commit 7578326 but this caused problems. It
was subsequently reverted in commit 6d2e9ee.
This change uses a common DHCPAgentContext and takes care to check for a
pre-existing setting in the dhcp_agent.ini. Only allowing a config
change if there is no pre-existing setting.
Please review and merge charm-helpers PR:
https://github.com/juju/charm-helpers/pull/422
Partial-Bug: #1831935
func-test-pr: https://github.com/openstack-charmers/zaza-openstack-tests/pull/157
Change-Id: I4848a3246d3450540acb8d2f479dfa2e7767be60
Also set upper constraint for ``python-cinderclient`` in the
functional test requirements as it relies on the v1 client
which has been removed. We will not fix this in Amulet, charm
pending migration to the Zaza framework.
Change-Id: If4d3b3cd79767b37fe6b74a1d6d399076c122bc8
Closes-Bug: #1843557
Enable support for configuration of FWaaS v2 firewall group
logging.
Configuration options mirror those for neutron-openvswitch
for security group logging.
This feature is currently only enabled for FWaaS v2 at Stein
for the charms (but is supported back to Queens in Neutron).
Change-Id: Ic60ee47078089c59ccb09b8659422e7ad7081149
Partial-Bug: 1831972
When 'sriov-numvfs' is configured in 'auto', only the devies set in
'sriov-device-mappings' are discovered and automatically configured.
Change-Id: I1be61a19639d366d787fb92815c3a8a5c302fbda
Closes-Bug: #1818975
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
When clouds have a large number of hosts, the default size of the ARP
cache is too small. The cache can overflow, which means that the
system has no way to reach some ip addresses.
Setting the threshold limits higher addresses the situation, in a
reasonably safe way (the maximum impact is 5MB or so of additional RAM
used). Docs on ARP at http://man7.org/linux/man-pages/man7/arp.7.html,
and more discussion of the issue in the bug.
Change-Id: I329ec51eff85a2a99a929c67ff0c68b3b36d7273
Closes-Bug: 1780348
Currently it is a requirement to have a network node with an l3 agent
running in the dvr_snat mode even for DVR deployments that do not use
SNAT or have a very limited usage of SNAT.
It is not possible to disable snat completely:
https://bugs.launchpad.net/neutron/+bug/1761591
Neutron creates a network:router_centralized_snat port and if it is not
possible to find a dvr_snat agent to schedule it on there are various
side-effects which are not seen at first. For example, Designate stops
creating records for floating IPs and Neutron/Designate integration is,
therefore, not functional.
The Neutron DVR documentation says that dvr_snat should be used on
network nodes. However, there is nothing restricting a DVR deployment
from using dvr_snat l3 agents on every compute node and not having
dedicated network nodes.
This change modifies neutron-openvswitch to optionally enable dvr_snat
l3 agent mode (this includes supporting L3HA routers if enabled). As a
result, it is possible to have deployments without neutron-gateway thus
saving on the amount of required nodes. Care should be taken when a
large amount of L3HA routers is used and using DVR routers without L3HA
is a recommended.
Change-Id: Iad3a64967f91c81312911f6db856ce2271b0e068
Closes-Bug: #1808045
Add support to enabling logging of security groups for
OpenStack Queens or later; this feature is enabled via
the neutron-api charm, with local charm configuration
options to allow control of rate and burst limits and to
set a local log output directory if require (allowing log
data to be written to a separate partition for example).
The feature is only compatible with the openvswitch firewall
driver and will not be enabled if this configuration option
is not set.
Basic deployment tests changes is included here since
nova-cloud-controller unit and relation was missing before,
and it leads to CI constantly failing.
Corresponding charm-helpers change:
https://github.com/juju/charm-helpers/pull/228
Change-Id: Id6ed09f714981e87838186d51a4f5e693bedb1d3
Closes-Bug: #1787397
Depends-On: https://review.openstack.org/602355
This brings this charm inline with the neutron-gateway charm
in terms of configurability when using a local dhcp agent.
Change-Id: Idc4f7735aaa9236d8a476fd3bae6aaf52b9dc043
Closes-Bug: 1777888
This allows more fine grained control over the bond mode
and LACP settings. Directly mapped to what OVS-DPDK configuration
exposes.
Change-Id: I1cca1043058f1ec99f194c1bdb611ebd603d646d
The current charm does not support creating and managing bonded network
interfaces. They are managed externaly. This is not possible when DPDK
is enabled. In this case OVS exposes the DPDK bond PMD which enslaves
the corresponding attached bond interfaces.
The new dpdk-bond-mappings configuration option allows such configuration
where mac:bond is specified. When the data-port configuration is processed
dpdk-bond-mappings are consulted to identify if the port belongs to a bond.
If this is true - then the bond is created with the mac designated interface
and the bond is added to the bridge. Subsequently more interfaces can be
added to the same bond.
Change-Id: I0224caaa1c2431c793c4f64caa7fc9e95b972fd7
Some NICs do not work with vfi-pci or uio_pci_generic. E.g. mxl4/mlx5
which uses relies on the OFED or Kernel drivers (post 4.14).
In this cases we don't want to generate entries in /etc/dpdk/inerfaces.
Here we change the configuration processing behavior. The charm will omit
adding entries in the aforementioned file when the value is not set.
The default value is changed to empty (i.e. None)
Change-Id: I2fb9f0404adbbee0f298729467794e172bae2d98
Adds a config option and calls to enable IPFIX exporting on all OVS
bridges created on a system by the OVS charm.
Closes-Bug: 1768016
Change-Id: Id2591ac5f39319d50ba235f6b9b5d493e7885d3a
Drop support for deployment from Git repositories, as deprecated
in the 17.02 charm release. This feature is unmaintained and has
no known users.
Change-Id: Ib954ddd1fb63d409af77949d8e76a6d6da8f2cde
Adds a dns-servers config option for specifying the forwarding
dns servers to be used by the dnsmasq services on the neutron
dhcp agent. This enables services using internal dns to also
specify the forwarding dns servers in order to resolve hosts
outside of the neutron network space.
Note: this option only takes effect when the
enable-local-dhcp-and-metadata flag is set to True.
Change-Id: I510d163dd9738477b15497b25266e73a50368539
Implements: blueprint internal-dns
Closes-Bug: #1713721
SR-IOV interfaces are currently only configured on charm
installation and not after seubsequent reboots.
The VFs need to be configured before the Neutron SR-IOV
agent is started. Charms should also really not be involved
in boot time system configuration. Due to these factors
this commit adds a init script and corrensponding systemd
unit file and upstart job to handle the boot-time configuration.
Keep configure_sriov function for runtime configuration. Add
warning about runtime configuration disrupting network service.
Add restart of Neutron SR-IOV agent after runtime configuration.
Cap value of sriov-numvfs at each interfaces sriov_totalvfs value.
Change-Id: I7bde7217bf027db09ded35a262c214ccb11d6d86
Closes-Bug: #1697572
Adds config option worker-multiplier to allow
configuring the number of workers used for the
metadata api when using local dhcp.
Change-Id: Ie3a7d6aab0d9902a6637637fbf75b2df3ec084b1
Closes-Bug: 1707618
Add a new option to provide the ability to specify flags in the
dnsmasq.conf file. This allows users to configure the dnsmasq
processes used by the neutron-dhcp-agent when local dhcp and
metadata are enabled for provider networks.
Change-Id: I2bab8a00322afb0f81986001c86f0ef4fc535651
Closes-Bug: #1684231
Neutron has supported use of a native openvswitch firewall driver
for a few releases; OpenStack Mitaka on Ubuntu 16.04 has the
required kernel and openvswitch versions to support this feature.
Add a new firewall-driver configuration option to support use
of the openvswitch native firewall; the default remains as the
iptables_hybrid driver, and users can switch to the openvswitch
driver if they are deployed on Ubuntu Xenial or later.
Change-Id: I4c228c5cbbff7f9673c1028ee4b075edba1fdc13
Closes-Bug: 1681890
When configuring data-port parameter with "ovs-bridge:linuxbridge"
a veth pair will be created to connect these two bridges. Name of
these virtual interfaces will be "veth-ovsbridge_name" and
"veth-linuxbridge_name".
Problem: When deploying neutron-openvswitch charm on a node contain
only one interface, we are not able to connect an ovs Bridge to
the physical interface because it is assigned to juju Bridge.
Change-Id: I5be72b9cc5948f5f791d522d1b46fd27e7303613
Closes-Bug:#1635067
SR-IOV network for OpenStack release later than Mitaka requires the
use of the neutron-sriov-agent to support management of SR-IOV PF
and VF interface state by Neutron - said interfaces are still
consumed directly by nova-compute/libvirt via PCI device allocation
scheduling for instances.
Add new configuration options to the neutron-openvswitch charm to
support enablement of the SR-IOV agent; this could have been done
automatically from data presented from neutron-api, but its possible
that cloud deployments may only have subsets of compute nodes that
are SR-IOV enabled in terms of hardware.
Enabling this option ('enable-sriov') will install and configure
the neutron-sriov-agent; configuration of SR-IOV PF's are made
using the 'sriov-numvfs', which by default automatically configures
all SR-IOV devices on every machine to the maximum number of VF's
supported by the device. This option can be used to configure
devices at an individual level as well.
Finally, neutron needs to understand what underlying provider
network each SR-IOV device maps to - this is configured using the
sriov-device-mappings configuration option.
Change-Id: Ie185fd347ddc1b11e9ed13cefaf44fb7c8546ab0
- Remove Precise-Icehouse Amulet test definitions if they exist.
- Add Xenial-Newton Amulet test definitions.
- Add Yakkety-Newton Amulet test definitions.
- Use the percona-cluster charm in tests instead of the mysql charm.
Change-Id: Id9ca2fc92aebd310c03c9e0f11ef7354a641d2fa
systemd is used instead of upstart by default since Ubuntu 15.10
(Wily). This adds systemd init file support for nova services
that are deployed from source.
Change-Id: I7d031e86853a3fb8b91501dc6bbd7f5f1b67701d
openstack-origin-git currently only supports YAML that specifies
the git repositories to deploy from.
This adds support for default openstack-origin-git values. The
default values supported are: icehouse, kilo, liberty, mitaka,
and master. For example: openstack-origin-git=master.
Change-Id: I032cb58283d54a9ccfcc268a7fd70b460a03aa58
Note that this change only impacts use of this charm when
Distributed Virtual Routing is enabled in a deployment.
Switch the generated configuration to use "new" style external
networks when ext-port is not set. In this case we configure:
external_network_bridge = (intentionally blank)
gateway_external_network_id = (blank)
The current template configures external networks by using the default
external_network_bridge=br-ex (implied when not set). This activates
legacy code which assumes that a single external network exists on
that bridge and the L3 Agent directly plugs itself in.
provider:network_type, provider:physical_network and
provider:segmentation_id are ignored. You cannot create multiple
networks and you cannot use segmented networks (e.g. VLAN)
By setting external_network_bridge = (intentionally blank) the L2
Agent handles the configuration instead, this allows us to create
multiple networks and also to use more complex network configurations
such as VLAN. It is also possible to use the same physical connection
with different segmentation IDs for both internal and external
networks, as well as multiple external networks.
Legacy/existing configurations where ext-port is set generate the same
configuration as previous and should continue to work as before.
Migration from legacy to new style configuration is not supported.
Change-Id: I3d06581850ccbe5ea77741c4a546e663b2957a91
Closes-Bug: #1536768
Add full support for DPDK; this includes a number of configuration
options to allow the number of cores and memory allocated per
NUMA node to be changed. By default, the first core and 1024MB of
RAM of each NUMA node will be configured for DPDK use.
When DPDK is enabled, OVS bridges are configured as datapath type
'netdev' rather than type 'system' to allow use of userspace
DPDK packet processing; Security groups are also disabled, as
iptables based rules cannot be applied against userspace sockets.
DPDK device binding is undertaken using /etc/dpdk/interfaces and
the dpdk init script provided as part of the DPDK package; device
resolution is determined using the data-port configuration option
using the <bridge:<mac address> format - MAC addresses are used
to resolve underlying PCI device names for binding with DPDK.
It's assumed that hugepage memory configuration is either done as
part of system boot as kernel command line options (set via MAAS)
or using the hugepages configuration option on the nova-compute
charm.
Change-Id: Ieb2ac522b07e495f1855e304d31eef59c316c0e4
This change allows nova-compute nodes to also run Neutron DHCP and Metadata
agents, allowing deploying without the neutron-gateway charm in VLAN and
flat networking configurations.
Only useful if l3 routing, vpnaas, fwaas and lbaas services are not required.
John P Lettman