The mock third party library was needed for mock support in py2
runtimes. Since we now only support py36 and later, we can use the
standard lib unittest.mock module instead.
Note that https://github.com/openstack/charms.openstack is used during tests
and he need `mock`, unfortunatelly it doesn't declare `mock` in its
requirements so it retrieve mock from other charm project (cross dependency).
So we depend on charms.openstack first and when
Ib1ed5b598a52375e29e247db9ab4786df5b6d142 will be merged then CI
will pass without errors.
Depends-On: Ib1ed5b598a52375e29e247db9ab4786df5b6d142
Change-Id: I8eedfa05c07067bb9a0d3a331d1868210534d84c
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
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
The current implementations use of a specific interface to build
FQDN from has the undesired side effect of the ``nova-compute`` and
``neutron-openvswitch`` charms ending up with using different
hostnames in some situations. It may also lead to use of a
identifier that is mutable throughout the lifetime of a deployment.
Use of a specific interface was chosen due to ``socket.getfqdn()``
not giving reliable results (https://bugs.python.org/issue5004).
This patch gets the FQDN by mimicking the behaviour of a call to
``hostname -f`` with fallback to shortname on failure.
Add relevant update from c-h.
Depends-On: I82db81937e5a46dc6bd222b7160ca1fa5b190c10
Change-Id: Ic8f8742261b773484687985aa0a366391cd2737a
Closes-Bug: #1839300
If a new version of the charm is used to install a version of
OpenStack prior to Stein, do not enable the FQDN registration.
Change-Id: I64afa582cdfadafcd249ddfbeec267ba610d166a
Closes-Bug: #1846781
The change of behaviour will only affect newly installed
deployments on OpenStack Train and onwards.
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.
Related-Bug: #1839300
Needed-By: Ia73ed6b76fc7f18014d4fa913397cc069e51ff07
Change-Id: Iee73164358745628a4b8658614608bc872771fd1
* The goal of this change is to enable the ability to configure only the
VFs that are configured through the charm and not fallback to the
blanket configuration.
* This python version of the script brings unit-tests that fully covers
it.
* Move the the template files to `files` and modify `neutron_ovs_utils`
accordingly.
Closes-Bug: 1832379
Depends-On: https://review.opendev.org/#/c/664837/
Change-Id: I7ad1ebc16883bda23cbad89a852e7e8f88f49c49
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 an isolated provider network with no virtual routers metadata
access occurs in the qdhcp netns.
Without the force_metadata option in dhcp_agent.ini and the haproxy
package installed ns-metadata-proxy is not enabled. ns-metdata-proxy
sits in the ip netns and proxies requests from 169.254.169.254 to the
nova-api-metadata service outside the netns.
This change adds the force_metadata option and installs haproxy when
enable-local-dhcp-and-metadata is True.
Closes-Bug: #1831935
Change-Id: Iaad1501e8d7d58888ef0917b6700d22a7cf05ecf
This charm is used in containers when deploying Octavia; sysctl
can't be updated from within a LXD container, so skip the call
to apply sysctl configuration if the unit is running in a
container of any sort.
Change-Id: If3c40fa6c8b6e5448293caf726088d152f6eeee8
Stop the charm from uninstalling keepalived when
using dvr since it also removes neutron-l3-agent.
Change-Id: I62d4cd2ee635ce793e37d4760387047b1b38f973
Closes-Bug: #1819499
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
If packages have been purged off the system then trigger a
restart of nova-compute by sending a restart trigger via the
neutron-plugin relation.
Change-Id: I5c8272d8c83b5112b6d8cebbbf3c485b87b7ef31
Closes-Bug: 1802304
Switch to execution of Neutron agents under Python 3 for
OpenStack Rocky; this is triggered by the nova-compute charm
mutating the container scoped neutron-plugin relation post
OpenStack series upgrade.
Update default smoke test target to bionic-rocky.
Change-Id: Ic5e96336b6a2ca474fc28d358553c6a05e1a75ce
Fix use of OVS DPDK context by direct use of methods on context
for OVS table values.
For modern OVS versions that require the PCI address of the
DPDK device for type=dpdk ports, use a hash of the PCI address
for the port name rather than the index of the PCI device in
the current list of devices to use; this is idempotent in the
event that the configuration changes and new devices appear
in the list of devices to use for DPDK.
Only set OVS table values if the value has changed; OVS will
try to re-allocate hugepage memory, irrespective as to whether
the table value actually changed.
Switch to using /run/libvirt-vhost-user for libvirt created DPDK
sockets, allowing libvirt to directly create the socket as part
of instance creation; Use systemd-tmpfiles to ensure that the
vhost-user subdirectory is re-created on boot with the correct
permissions.
Scan data-port and dpdk-bond-mappings for PCI devices to use
for DPDK to avoid having to replicate all PCI devices in data-port
configuration when DPDK bonds are in use.
Change-Id: I2964046bc8681fa870d61c6cd23b6ad6fee47bf4
Currently, upgrading this charm on a host that is running
ovs >= 2.6 will break because the OVS_DEFAULT config file
is not expected to be written by the charm.
Change-Id: I33352deb3b60231347045d5f39f3508a29dda61e
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
Support for the ZeroMQ messaging driver has bit-rotted over
the last few years across the OpenStack charms; drop support
for ZMQ inline with deprecation notices issued in 17.02 charm
release.
Change-Id: I3a4f4bc84327ee2e269d3ebd93d102494102b05e
The 16.10 release of the neutron-openvswitch charm changed the
file management strategy of /etc/default/openvswitch-switch
config file from managing the file when dpdk is enabled to always
managing the file. Additionally, the template file was changed
in the 16.10 release to modify the file header (commit 4463c334).
These two changes guarantee that the contents of the file will
change when upgrading the charm.
The changing file contents causes the openvswitch-switch service
to be restarted, which in turn causes a data plane outage. This
commit fixes that by migrating the /etc/default/openvswitch-switch
to be charm managed without restarting the openvswitch-switch
service.
The change will only attempt to migrate versions of the file
which were created before 16.10 by searching for a marker in the
rendered version of the file which was added in 16.10.
Change-Id: Icc0f326991be239b88a57292740473f501181ebb
Closes-Bug: #1712444
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
All contributions to this charm where made under Canonical
copyright; switch to Apache-2.0 license as agreed so we
can move forward with official project status.
Change-Id: I7bd44dc15ad951bf2536e5ee10de01ec592b8970
John P Lettman