When QoS is set in the neutron-api charm, the neutron-openvswitch
charm needs to add 'extensions = qos' to the sriov_agent.ini
file.
Closes-bug: #1938277
Change-Id: I44fbf5991d2606161b1bcbc064d4bc68a2fbbb5b
fwaas_v2 extension is added in l3_agent.ini by default from stein.
However with the newly introduced neutron-api configuration parameter
enable-fwaas, the extension have to added only when it is set to true
on neutron-api charm.
neutron-api charm adds enabled-fwaas as relation data in the commit
https://review.opendev.org/c/openstack/charm-neutron-api/+/806676.
This patch removes special handling of fwaas_v2 as l3_extension_plugins
is already updated in relation data based on neutron-api enable-fwaas
configuration.
Add python3-neutron-fwaas in py3 package list only for rocky release. The
package is already part of dependency of neutron-l3-agent until Ussuri
release and the dependency will be removed from Victoria release in
package control files.
Synced charmhelpers to get related changes
https://github.com/juju/charm-helpers/pull/635
Closes-Bug: #1934129
Change-Id: I1546f45635bfd7af76001c1df4f99d219a9d8039
The neutron-dhcp-agent might rely on options defined in
openvswitch_agent.ini. By default this config file is not passed to
neutron-dhcp-agent daemon, and therefore those options are not
loaded and fall back for the default values and by that inhibits
the desired behavior.
Charm helpers' PR: https://github.com/juju/charm-helpers/pull/615
Depends-on: I39024855c3e42ee135b6ad5e7618a770219b6994
Closes-bug: #1832021
Change-Id: I134c8077ee52ccdb4e383109ecbea27ed1633fb8
f832f1073d47a430111c59563962922dfe37a0a5 addressed LP: #1635067 by
adding support for using pre-created Linux bridges in the data-port
config option.
The same use-case of reusing a single physical interface for VLAN
interfaces and plugging it into an OVS bridge can be addressed in a
different way by plugging the physical interface directly into the OVS
bridge and creating VLAN interfaces on that physical interface - this
does not require the use of veth pairs which is problematic due to the
performance reasons and lack of support for in netplan for veth pairs at
the time of writing.
There is a procedure to move from the setup with Linux bridge and veth
pair used to the one that does not which will be documented to migrate
the existing environments in-place.
Partial-Bug: #1877594
Change-Id: I5e455fa701cc2f5248ccfd9ed15f3c902aacb1ef
Co-authored-by: Aurelien Lourot <aurelien.lourot@canonical.com>
This restores OVS_DEFAULT to the BASE_RESOURCE_MAP.
There were some changes in commit ad7f870c that moved OVS_DEFAULT
out of the BASE_RESOURCE_MAP, which resulted in no more rendering
of /etc/default/openvswitch-switch for non-DPDK deployments.
Closes-Bug: #1925962
Change-Id: I8bc6e0c20e5702db5a44fda531b6a59ada5bee1e
Deprecate ext-port in favour of data-port and bridge-mappings. From now
on ext-port value will be ignored if data-port is specified in the
config. Log an error in the unit's log and display it in the unit's
status so that the user is aware of misconfiguration.
Update and add new unit tests to account for the introduced changes.
Add a new functional test case that verifies correct handling of
data-port and ext-port config options.
Signed-off-by: Przemysław Lal <przemyslaw.lal@canonical.com>
Change-Id: I4c6febbb56f9a61ff2519b60d2a746c9580a8f2d
Enable marking of OVS bridges and ports as managed by
charm-neutron-openvswitch. This enables more advanced use cases like
implmentation of idempotent config changes or cleanup of stale OVS
configuration.
Include functional test case that verifies whether external-ids are
properly set up on ports and bridges.
Sync charmhelpers.
Closes-Bug: #1917025
Partial-Bug: #1915967
Signed-off-by: Przemysław Lal <przemyslaw.lal@canonical.com>
Change-Id: I343f2c8258b7b8b91417dc6efc5bfe95351392a9
Replace deprecated code that was used for setting up DPDK ports and
bonds with calls to charmhelpers functions.
Pass DPDK configuration using ifdata and portdata dicts instead of
making direct ovs-vsctl calls.
Move installation of sriov-netplan-shim to the bash wrapper. This
resolves problems with non-working imports of sriov-netplan-shim in
charmhelpers.
Update unit tests to reflect that change.
Signed-off-by: Przemysław Lal <przemyslaw.lal@canonical.com>
Change-Id: Ica6f3ea66136bca6c77a5fb55ad7ef5d95aa1f6a
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
The change in I7a3ddf91d4b2ae6aa0806d97c45b59e8a951f67f replaced
the historic SR-IOV support with tooling from the networking-tools
PPA.
Remove the now orphaned template files and references to them in
the code.
Related-Bug: #1908351
Change-Id: Ic22b3dc8a5dd7ec3358571d9725ccc9e3dad64f4
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
Ensure that the neutron-common package is installed prior to
assessment of any feature requirements based on OpenStack release.
This ensures that the OpenStack release is assessed accurately
avoiding any issues with guesswork and assumption in the charm
code.
Change-Id: I86a73fe363c91627f59b1c181d9c2f75f7b06e0b
Closes-Bug: 1878750
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
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
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
Inline with the neutron-gateway charm, move availability_zone
configuration to the neutron.conf configuration file to ensure
that its set consistently for all neutron agents that may be
running on the unit.
Change-Id: If9438302f8f889a1cbaf93f8a460e190e551241b
Closes-Bug: 1829537
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
When neutron-openvswitch-agent is using the openvswitch firewall,
it needs the nf_conntrack_ipv4 module to be loaded. Usually, this
module gets loaded by some other external tool, but in case this
does not happen, neither the charm nor neutron will load it, so
all traffic to the instances in this host will fail. This patch
fixes that by explicitly loading the module.
Change-Id: Ia788e870c124de7da17961c02259cfe80938e5d2
Closes-bug: #1834213
To improve visibility of DPDK configuration issues, sprinkle
DPDK part of configure_ovs with lots of DEBUG level log messages.
Change-Id: Ica9848dcefb43f8a05546b77024d4b7d35dde4f9
MTU is not being set on the dpdk devices when a dpdk bond is
being requested. Currently the mtu is being set in
neutron_ovs_utils.configure_ovs by iterating over the dictionary
returned by neutron_ovs_context.resolve_dpdk_bridges. But this
context is expecting the data-port config option to be a list of
bridge:mac mappings. In the case of a dpdk bond however,
data-port is set of bridge:bond-name mappings. The context then uses
the bond name as if it were a mac address to find the
underlying pci device which naturally fails and then returns
an empty context. This is fine as configure_ovs then moves on
to setup the dpdk bonds correctly. Unfortunately the code
to apply mtus to the devices in the case of a bond was missing
and this change adds it in.
Change-Id: I2fb8ccf48ffd1a3ab227b883ceacac89ff57ea02
* 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
For OpenStack Queens and later instances are setup with vhostuser
ports in server mode, with the OVS side of the port connecting
as a client to the vhostuser socket on disk; as a result we no
longer need to pass permissions information via dpdk-extra (the
two passed options are not valid in later OVS versions).
In addition, we should also whitelist the devices we're going to
use; this ensures that EAL initialization does not take an extended
period of time reducing the amount of time taken to restart OVS.
Change-Id: I224e778de0ed6e279b2de7f4f46781df33121165
Closes-Bug: 1833734
Closes-Bug: 1793729
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
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>
To configure SRIOV devices it was expected that the 'sriov-numvfs'
config option to be changed but during an initial setup this not
happens.
In this commit we remove the condition but add a logic in
PCINetDevice to avoid reconfiguring PF devices if not necessary.
Change-Id: Ib8232b29f76ca7e25e1cd835d5e31a276000f1d4
Closes-Bug: #1817079
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
We should reset PF before to be able to allocate new VFs. This commit
is moving that part in PCIDevDevice that to refactor the code and in
order to fix related issue #1817079 in the next commit.
Change-Id: I17ba3908469ab604bf5eda3528e0b50b2e5e968f
Related-to: ##1817079
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
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
The DVR package neutron-l3-agent depends on python-neutron-fwaas or
python3-neutron-fwaas. On Rocky without being explicit it will
incorrectly install the python2 version which in turn installs many
python2 dependencies.
This change explicitly adds python3-neutron-fwaas as a dependency on
Rocky and updates python-neutron-fwaas as a purge package.
Change-Id: Idb537df84b044e8ea92527a5f56ab06a37b9ffad
Closes-Bug: #1803744
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
The vhost-user tmpfiles configuration is only applicable in deployments
using libvirt/kvm with nova-compute.
Ensure appropriate user and group exists before installing tmpfiles.d
configuration.
Change-Id: I471ff459e5f979cb6781193fb074f6f5f7ee967f
Closes-Bug: 1792414
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
The neutron-plugin-openvswitch-agent package has been dropped @ Rocky.
Pre-install neutron-common and ensure any previously cached os_release
value is reset when evaluating which OpenStack release is being installed,
ensuring that the correct package for the neutron-openvswitch-agent is
used.
Closes-Bug: #1788266
Change-Id: I1224aa7f5e7caa6a8aaf2ab3043fac9c62735749
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
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
OVS 2.6.0 introduces new mechanisms to configure the DPDK netdev
provider. It now relies on the database and allows dynamic runtime
configuration. Network interface binding is more fine grained by
specifying the NIC PCI address and not relying on special port naming
and indexing.
Here we introduce the support of post 2.6.0 OVS-DPDK and change the
relevant tests.
Change-Id: Ic0185097d65df04a2b566e16cb22bcbd088eed3e
A recent commit landed with failing unit tests, but due to
gate misconfiguration this was not picked up during pre-commit
testing.
Fixup offending code.
Change-Id: I20488efabe91b2423c85dd4e7474cbaf9a0a0261
