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
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
Leaving firewall_driver unconfigured has expose an error
when configuring vlan trunk ports while security groups
are disabled. Setting it to NoopFirewallDriver allows it
to work properly.
Change-Id: I65ace64e0a71f78fa857481fff0a874cc018d7d8
Closes-Bug: #1934904
This fixes a regression introduced in 16.3.0 neutron
release that causes non-offloaded ports to break on
hypervisors that have offloaded enabled.
Closes-Bug: #1931696
Change-Id: I1e884eac26d51c825736f34bcbfdccc906944b8d
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
The templates was missing a gate on the `instance_mtu` context
variable. Update template for all supported versions to be on
par with the neutrona-gateway charm.
Change-Id: I2468ce5e20150371a7472ecdd89f8d4b3b14c489
Closes-Bug: #1887817
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
* 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
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
Reverting as this change causes existing qdhcp namespaces to become
inaccessible.
This reverts commit 7578326c59.
Change-Id: I295fb21dc66b86a5259cb7ae06a92766cf246675
Ensure "rabbit_use_ssl" is specified in the [oslo_messaging_rabbit]
config section instead of "ssl" for Ocata, since "ssl" was not yet
introduced.
Change-Id: I61ed1575bb13d5104eb79e2554974e48bdf3de72
Closes-Bug: #1838696
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
* 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
veth pairs are currently being used to connect the qdhcp namespace
to the underlying bridge. This behaviour appears to only be needed
for old kernels with limited namespaces support (pre trusty).
Change-Id: If1f669de09e2499e74e88e2b72203047e7f9f957
Closes-Bug: #1832021
* It is necessary to enclose it in double quotes. If not, the
environment variable will be empty when sourced.
Change-Id: Ic4e50dec04eee3b4cdb9d790da4af37f39c07b31
Closes-Bug: 1832378
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
The stein version of python-oslo.messaging (9.0.0+) has removed
the following config options from the [oslo_messaging_rabbit]
section:
rabbit_host, rabbit_port, rabbit_hosts, rabbit_userid,
rabbit_password, rabbit_virtual_host rabbit_max_retries, and
rabbit_durable_queues.
The above change requires a sync from charm-helpers.
Additionally the transport_url directive has been moved to the
[DEFAULT] section.
These have been deprecated since Ocata, therefore this change
will be provided to pre-Stein templates in order to drop
deprecation warnings.
See release notes at:
https://docs.openstack.org/releasenotes/oslo.messaging/index.html
Change-Id: I77e3437a5241c9ded2ef5000639f984222bc4803
Closes-Bug: #1817672
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
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
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
The original fix description
https://review.openstack.org/#/c/541815/
Change-Id: Ifa9dca8cf634561dab0fee9a26711678a50379bf
Signed-off-by: Anton Kremenetsky <akremenetsky@dev.rtsoft.ru>
Closes-Bug: #1747964
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
iteritems() method is no longer exists in Python 3 dictionaries
which causes the neutron-openvswitch charm to throw an exception
if dnsmasq_flags option is set. Code has been changed to
items() method to work in Python 3.
Change-Id: I7eaae8f33ed0dc5c97ef478bfe9e1fbd7f79783f
Closes-Bug: #1738198
This patch adds support for reading the 'enable-qos' setting from the
neutron-plugin-api relation and adding 'qos' to the extension_drivers setting
if it is True. This is part of a wider set of changes to support QoS across the
neutron charms.
A charmhelper sync was performed to pull in the QoS update to the
NeutronAPIContext.
Note: Amulet tests will fail until the corresponding neutron-api change
lands
Depends-On: I1beba9bebdb7766fd95d47bf13b6f4ad86e762b5
Change-Id: I9d857a4f2a25c6080963a0f3f6e6592c0a77d133
Partial-Bug: #1705358
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
A new mitaka neutron.conf template was introduced into the charm
lately, so both rpc_response_timeout and report_interval need to
be set into the template as well.
Change-Id: I3e049e5366aa3471ce63fea57822e7068e7db5b9
Partial-Bug: #1685788
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
These options are set in the neutron-api charm centrally, and
this patch allows neutron-openvswitch charm to continue doing:
1, polling_interval
Just used by neutron l2 agents, so neutron-openvswitch charm
gets it via it's relations and set it in [agent] of ml2_conf.ini
or openvswitch_agent.ini(>=Mitaka)
2, rpc_response_timeout
Used by all neutron agents, so both neutron-gateway charm and
neutron-openvswitch charm get it via it's relations and set it
in [default] of neutron.conf
3, report_interval
Used by all neutron agents, so both neutron-gateway charm and
neutron-openvswitch charm get it via it's relations and set it
in [agent] of neutron.conf
Change-Id: I76c0c75d5f3b4fdd1eb3242b53fde2e829fedca5
Partial-Bug: #1685788
Use oslo_messaging_notifications for mitaka or later releases
including setting the transport_url to the value provided by
the AMQP context.
This removes use of deprecated configuration options for
ceilometer notifications.
Change-Id: I6f6f3d7f2e423aecf5be7cab08da560e291e5845
On Kilo and Liberty the agent is called 'neutron-plugin-sriov-agent'.
Add unit-test to verify package determination.
Add functional test to verify that configuration is written.
Change-Id: I8a40c12cbb7f6a692b19105d5c029fd7f2829504
Closes-Bug: #1696691
Specify the dns_domain value in dhcp_agent.ini configuration
file in order to indicate the dns search domain which should
be advertised by the dnsmasq DHCP server.
Note, for neutron-openvswitch - this only takes effect when
the enable-local-dhcp-and-metadata flag is set to true.
Change-Id: If3529cf32a6e10d44c86423151cdacdad50445f8
Implements: blueprint charms-internal-dns
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
The 'neutron.openstack.common.notifier.rpc_notifier' notification
driver key was removed from neutron in Ocata; 'messaging' has been
provided directly from oslo.messaging since icehouse, so switch to
using the newer, correct value for configuration of notifications.
Change-Id: I67e66caefdabc88e7fa5762133b4313fd84c840b
Closes-Bug: 1681452
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
Erlon R. Cruz