These updates, on the master branch, are to support testing the caracal
packages and support of the charms for caracal. They do NOT lock the charms
down, and don't change the testing branches to stable branches.
Update unit-test to deal with Py3.11 which is run on Debian Buster and
doesn't have /etc/lsb/release file (incorrect mocking issue).
Change-Id: Icddaf9f7b091a09ef4627384cd349e43b34b1325
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
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
f832f1073d 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
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
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
Includes updates to charmhelpers/charms.openstack for cert_utils
and unit-get for the install hook error on Juju 2.9
* charm-helpers sync for classic charms
* rebuild for reactive charms
* ensure tox.ini is from release-tools
* ensure requirements.txt files are from release-tools
* On reactive charms:
- ensure master branch for charms.openstack
- ensure master branch for charm-helpers
* Remove mock for unit_get() as removed from the context module
Change-Id: I1c68e1ad512d947b62c8cef6d1cc585270f64972
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
Add OVS to OVN migration at the end of the regular gate test. This
adds only 5-10 minutes to each job and we want to confirm this
works from focal-ussuri and onwards as this is the point where we
recomend our end users to migrate from OVS to OVN.
Do ch-sync.
Merge after https://github.com/juju/charm-helpers/pull/511
Func-Test-Pr: https://github.com/openstack-charmers/zaza-openstack-tests/pull/365
Depends-On: Ifa99988612eaaeb9d60a0d99db172f97e27cfc93
Change-Id: Ia4b1d3a9e642b540d1e04adc0363f9b3e11f37cd
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
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
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
/etc/neutron/secret.txt is used to store the UUID to configure
the shared secret in neutron-metadata-agent and the nova-api-metadata
service for authentication of metadata requests from instances.
Ensure that this file can only be read by the root user.
Change-Id: I6a18ebabade887922c13824c23ad5e0a8da74ba8
Closes-Bug: 1847230
* get a list of l3 plugins to enable based on relation data coming from
neutron-api;
* refactor adding fwaasv2 service plugins to the l3 agent to accommodate
the l3_extension_plugins change.
See https://github.com/juju/charm-helpers/pull/370
See LP: #1842353
Change-Id: Ic3a8e302942ed331bc3d80223e123c13d61db3b2
Closes-Bug: #1842353
The original implementation in [0] relied on the template content
appearing at the ``Stein`` release.
With the addition of sharing of this value on the subordinate
relation in [1] we need this gating in the context too.
0: Iee73164358745628a4b8658614608bc872771fd1
1: I75cbc5eb97cf3603ffa5a9a49670411288d90520
Change-Id: I2b252fd3512c07bb7bccd388809b0514ebcd5bde
Closes-Bug: #1845303
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
If you want to have vrrp watch the external networking interface
today, the option ha_vrrp_health_check_interval [1] detects a failure
it re-triggers the transitional change - which works if the external
physical interface fails because the ping will fail.
In fact, we've tried to enable it before [2], but then we had to
revert it [3] due to instability issues [4] in previous releases of
OpenStack. Maybe the previous instability issue [4] was caused by
another keepalived issue mentioned in the comment [5], now I have
tested this option again, it works.
This is how neutron allows monitoring southbound network today, so
I would suggest we add this capability into the charm again.
This is a patch for charm-neutron-openvswitch side to support
enable-dvr-snat=True option which allows running gateway components
on compute nodes (as of 19.04 charms, see [6])
[1] https://docs.openstack.org/ocata/networking-guide/ \
deploy-ovs-ha-vrrp.html#keepalived-vrrp-health-check
[2] https://review.opendev.org/#/c/601533/
[3] https://review.opendev.org/#/c/603347/
[4] https://bugs.launchpad.net/neutron/+bug/1793102
[5] https://bugs.launchpad.net/neutron/+bug/1793102/comments/5
[6] https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1808045
Change-Id: Ic7e751dd876cc67805e841e109a4f955ad80be47
Closes-Bug: 1825966
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>