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
Adds a config option and calls to enable IPFIX exporting on all OVS
bridges created on a system by the OVS charm.
Closes-Bug: 1768016
Change-Id: Id2591ac5f39319d50ba235f6b9b5d493e7885d3a
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
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
Ensure that a full copy of the SR-IOV resource map is made when
building the full resource_map for the charm; this avoids any
direct manipulation of the constant SRIOV_RESOURCE_MAP and
some associated unit test failures.
Change-Id: Ia1d1da9e625fa85dc0afc8931b11bc2b30b41c09
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
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
- sync charmhelpers with fix-alpha helpers
- fix up code where the alpha comparisons are done
- fix tests which assumed mocks would just work on os_release()
Change-Id: Ifa495c37adeb24aa98e4e5e181b90cbbd5c0cddb
Related-Bug: #1659575
When configuring data-port parameter with "ovs-bridge:linuxbridge"
a veth pair will be created to connect these two bridges. Name of
these virtual interfaces will be "veth-ovsbridge_name" and
"veth-linuxbridge_name".
Problem: When deploying neutron-openvswitch charm on a node contain
only one interface, we are not able to connect an ovs Bridge to
the physical interface because it is assigned to juju Bridge.
Change-Id: I5be72b9cc5948f5f791d522d1b46fd27e7303613
Closes-Bug:#1635067
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
MTU scripts are no longer needed as MAAS 1.9 can set the mtu and
bring up the interfaces.
The charm has no systemd versions of the 'os-charm-phy-mic-mtu'
and 'ext-port' scripts either so for xenial to set mtu sizes
on physical nics use MAAS 1.9 and appropriate network config
Change-Id: I3aa4d2a80a08dd605d4ae08d53f35282017e1009
Partial-Bug: 1566786
I've added support for 'availability_zone' parameter. I've added
'dhcp_agent.ini' template and implemented the parameter to be consumed
via 'neutron-plugin' relation settings.
Change-Id: I015a6dfcf89800043bd7dbf02b07da07d8a7d728
Closes-Bug: 1595937
Restart requests can be sent by related charms. A request to restart
services did not previously restart openvswitch. This change adds the
ability to restart it.
Closes-Bug: 1628093
Change-Id: I0f57d84e2cdaa103c18a1cdacd996f9421fba46c
Juju 2.0 provides support for display of the version of
an application deployed by a charm in juju status.
Insert the os_application_version_set function into the
existing assess_status function - this gets called after
all hook executions, and periodically after that, so any
changes in package versions due to normal system updates
will also be reflected in the status output.
This review also includes a resync of charm-helpers to
pickup hookenv and contrib.openstack support for this
feature.
Change-Id: Ia91a2de062fbc13fdb2b366217278bb96fc648fa
Add neutron-control interface to allow charms to send triggers to
restart neutron services managed by this charm
Change-Id: I0e44f7cab99db4fb9b5d2764859e16b30705e6fe
systemd is used instead of upstart by default since Ubuntu 15.10
(Wily). This adds systemd init file support for nova services
that are deployed from source.
Change-Id: I7d031e86853a3fb8b91501dc6bbd7f5f1b67701d
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
openstack-origin-git currently only supports YAML that specifies
the git repositories to deploy from.
This adds support for default openstack-origin-git values. The
default values supported are: icehouse, kilo, liberty, mitaka,
and master. For example: openstack-origin-git=master.
Change-Id: I032cb58283d54a9ccfcc268a7fd70b460a03aa58
Check to see if a restart trigger has been sent by the principle,
if it has then right the trigger uuid in to the neutron.conf to
trigger a service restart
Change-Id: I19649cb73dad94f4fe24412c0b8c37a28f30047d
Partial-Bug: 1571634
This fixes bug#1570411 where the add_bridge_port(...) function was
modified to include a port type but missed off port up and promisc
features.
Change-Id: I2a304270be97ed1eae5a7ceeb5777514460d8b4f
Closes-Bug: #1570411
Add full support for DPDK; this includes a number of configuration
options to allow the number of cores and memory allocated per
NUMA node to be changed. By default, the first core and 1024MB of
RAM of each NUMA node will be configured for DPDK use.
When DPDK is enabled, OVS bridges are configured as datapath type
'netdev' rather than type 'system' to allow use of userspace
DPDK packet processing; Security groups are also disabled, as
iptables based rules cannot be applied against userspace sockets.
DPDK device binding is undertaken using /etc/dpdk/interfaces and
the dpdk init script provided as part of the DPDK package; device
resolution is determined using the data-port configuration option
using the <bridge:<mac address> format - MAC addresses are used
to resolve underlying PCI device names for binding with DPDK.
It's assumed that hugepage memory configuration is either done as
part of system boot as kernel command line options (set via MAAS)
or using the hugepages configuration option on the nova-compute
charm.
Change-Id: Ieb2ac522b07e495f1855e304d31eef59c316c0e4
Add in pause/resume feature for maintenance mode along with tests.
Sync charmhelpers with support for the maintenance mode feature.
Change-Id: I075459e56ce34e78f5206d116208165aa43aae21
