This is a boilerplate section that will eventually
be added to the README for every charm that supports
the deferred restart feature.
Change-Id: I4aa805273f83b9cd88d96fa0e77b12e829cb2499
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
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
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
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
Note that this change only impacts use of this charm when
Distributed Virtual Routing is enabled in a deployment.
Switch the generated configuration to use "new" style external
networks when ext-port is not set. In this case we configure:
external_network_bridge = (intentionally blank)
gateway_external_network_id = (blank)
The current template configures external networks by using the default
external_network_bridge=br-ex (implied when not set). This activates
legacy code which assumes that a single external network exists on
that bridge and the L3 Agent directly plugs itself in.
provider:network_type, provider:physical_network and
provider:segmentation_id are ignored. You cannot create multiple
networks and you cannot use segmented networks (e.g. VLAN)
By setting external_network_bridge = (intentionally blank) the L2
Agent handles the configuration instead, this allows us to create
multiple networks and also to use more complex network configurations
such as VLAN. It is also possible to use the same physical connection
with different segmentation IDs for both internal and external
networks, as well as multiple external networks.
Legacy/existing configurations where ext-port is set generate the same
configuration as previous and should continue to work as before.
Migration from legacy to new style configuration is not supported.
Change-Id: I3d06581850ccbe5ea77741c4a546e663b2957a91
Closes-Bug: #1536768
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
Juju 2.0 provides support for network spaces, allowing
charm authors to support direct binding of relations and
extra-bindings onto underlying network spaces.
Resync charm-helpers to pickup support for new hookenv
tools and add data extra-binding to the charm metadata.
This allows the local endpoint IP for overlay tunnels to
be configured using network spaces.
Any existing configuration of os-data-network is preferred
over the new binding support if already set.
Change-Id: I0e2e3f51106b6c6483f22ce4abd04bcb098b484e
James Troup