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
* sync charm-helpers to classic charms
* change openstack-origin/source default to zed
* align testing with zed
* add new zed bundles
* add zed bundles to tests.yaml
* add zed tests to osci.yaml and .zuul.yaml
* update build-on and run-on bases
* add bindep.txt for py310
* sync tox.ini and requirements.txt for ruamel
* use charmcraft_channel 2.0/stable
* drop reactive plugin overrides
* move interface/layer env vars to charmcraft.yaml
* enable qos service plugin for neutron-api to ensure
migrate-ovn-db action is successful
Change-Id: I6f94ff3e557413b6096493f839c0a5f217c017d3
Closes-Bug: #1988089
Quotes around paramerer string because apt-add-repository requires
single parameter but networking-tools-source can contain multiple word entries.
Closes-Bug: #1980020
Change-Id: Ia59acbfb997e5df8638d8ad9135f11b121302815
Add ovs-record-hostname to the list of deferrable services, this service
was SRU'ed into Ubuntu >= Focal, when it's not mark as deferrable on
package upgrades will induce a restart of openvswitch-switch.
Change-Id: I4fa3256b39e62e9df223ab40f17f1677a621f293
Closes-Bug: #1923636
Related-Bug: #1915829
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
* charm-helpers sync for classic charms
* sync from release-tools
* switch to release-specific zosci functional tests
* run focal-ussuri as smoke tests
* remove trusty, xenial, and groovy metadata/tests
* drop py35 and add py39
Change-Id: Id5a191694d70ef745bd41206eaa2222c95f48dfe
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
The 'hirsute' key in c-h/core/host_factory/ubuntu.py:
UBUNTU_RELEASES had been missed out, and is needed for
hirsute support in many of the charms. This sync is to
add just that key. See also [1]
Note that this sync is only for classic charms.
[1] https://github.com/juju/charm-helpers/pull/598
Change-Id: I8518ef0545a788e7126dc2baf57029c74d4ba52b
* charm-helpers sync for classic charms
* build.lock file for reactive charms
* ensure tox.ini is from release-tools
* ensure requirements.txt files are from release-tools
* On reactive charms:
- ensure stable/21.04 branch for charms.openstack
- ensure stable/21.04 branch for charm-helpers
Change-Id: I3b8e6ccdf10bf5a128f67b233e0218e16a8765ab
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
The network-get --primary-address juju-info fails on pre-2.8.?
versions of juju. This results in a NoNetworkBinding error.
Fallback to unit_get() if that occurs for local_address().
Change-Id: I37d21fbaf951b1fe5bc03306b67012ac37b2e75b
The charm will attempt to do run-time configuration of
Open vSwitch prior to writing configuration files to disk and
restarting services when required.
When running in a container or on a system where it is required
to disable mlockall this will not work as the charm will attempt
to do run-time configuration of OVS prior to having (re-)started
it with the required ``--no-mlockall`` option.
Closes-Bug: #1906280
Change-Id: I8d98e6310aafcd840f3b4947ccc065c97069afe2
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
- Adds groovy to the series in the metadata
- Classic charms: sync charm-helpers.
- Classic ceph based charms: also sync charms.ceph
- Reactive charms: trigger a rebuild
Change-Id: I11e93eb9e6426fdaad1aea43e451523a251870f6
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
Alex Kavanagh