This is required for SR-IOV to work on OpenStack versions
Kilo, Liberty and Mitaka (unless you are the lucky owner of
NICs with the default vendor/product IDs '15b3:1004', '8086:10ca').
The option is deprecated in Newton and the default behaviour
onwards is to not perform the check (unless configured) and not
overrule Nova's scheduling decision. (See LP #1611302)
Re-work mechanism_driver templating. Current implementation
treats mechanism drivers 'hyperv' and 'sriovnicswitch' as
mutually exclusive for simplicity. This prohibits us from
adding functional test for verifying sriov statements in
configuration files.
Due to how neutron init scripts are laid out on various Linux
distributions put the [ml2_sriov] section in ml2_conf.ini instead
of its default ml2_conf_sriov.ini location.
Add a placeholder ml2_conf_sriov.ini with comment to point users
in the right direction.
Change-Id: I37da1c430a06417ff7f1bc9df2d984137688bba0
Closes-Bug: #1630387
This combination is supported since Newton. Additionally this
enables use of l2-population with L3HA since Newton.
Change-Id: Ifd7411ac8e0e24d95da791a36b2f523b34ded2a4
Closes-Bug: #1681891
Add the dns-domain config and enable-ml2-dns options, allowing the
user to enable DNS integration between Neutron and Nova. This enables
the DNS integration between Nova and Neutron for internal DNS services
when the enable-ml2-dns option is set to True.
Change-Id: Id5f828da003e056a882297ffdbf3df22e856d14a
Implements: blueprint internal-dns
- 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: I3d1a8993286f0e7a1037c03e6711015883f1b615
Related-Bug: #1659575
In order to support changes in the api-paste.ini file for the keystone
middleware of the neutron-api service by subordinates we need a generic
mechanism to pass wsgi middleware data via a relation.
The following approach is used in this change:
- relation data set by subordinates:
{'extra_middleware': [{
'type': 'middleware_type',
'name': 'middleware_name',
'config': {
'setting_1': 'value_1',
'setting_2': 'value_2'}}]}
- there may be many subordinates each with their own set of middleware
all of which should be taken into account
- besides a factory method for middleware other settings can be
specified, therefore, a generic config dictionary is used
- neutron-server has to be restarted as api-paste.ini is read upon
startup of the service
- api-paste.ini rendering code is added along with a template code
containing loops over a list of middleware provided in a context to
construct the following entries:
keystone = [name-1 ... name-m] <default_middleware>
[type-1:name-1]
key-1 = value-1
...
key-n = value-n
...
[type-m:name-m]
key-1 = value-1
...
key-k = value-k
- api-paste.ini defaults are copied from their respective upstream
neutron branches
Change-Id: I9449aa2e85b1523f24acdcee11ca1f635dda47c0
I've added basic support for "global_physnet_mtu" and "path_mtu"
options by allowing to configure them via charm parameters.
Change-Id: Ia95533418ccd4b7d1b96270633193ea34b1edecb
Partial-Bug: 1650579
- Add default-tenant-network-type config option to allow the default
network type for a tenant network to be set
- Fix rendering of overlay-network-type so that an empty string is
valid
Change-Id: Ib2325d273a0dd5e637f36113b951130387902777
Closes-Bug: 1533651
This patch adds hyperv mechanism driver to ml2_conf.ini template
and the required python package to the list of packages to install.
Change-Id: If23f22aea53ba5549160f44442567d57b8077af6
All contributors to this charm have agreed to the switch
from GPL v3 to Apache 2.0; switch to Apache-2.0 license
as agreed so we can move forward with official project status.
Change-Id: Ie7859853644fb819f1cd3062a2fea86766de0afb
Add a new configuration option to enable SR-IOV support across Neutron and
Nova; this involves enabling the required mechanism driver, and informing
the nova-cloud-controller charm that SR-IOV has been enabled, so that Nova
can use the correct scheduler filters for PCI device management.
Change-Id: I8938c22c8f4dc27bb0816fd8e5e6154a1407e93f
To cover the case when Nuage VSD & VSC are deployed outside of juju
framework.
Removed nuage-tarball from config file
Removed respective code form neutron_api_hook.py
Change-Id: I4518435ded9e1a4eb3d98cbb2e77f04b4f2dda61
Signed-off-by: sunny-verma <sunnyverma1992@gmail.com>
This advertises API readiness to subordinates via a new flag int the subordinate
relation. It determines readiness by the completion of required contexts. This
simply means the API service has enough of its topology completed to begin
servicing requests, and it has at least *started* the service (from the POV of
the init system). Its up to the subordinate service to ensure the API is
functional.
It also allows subordinates to specify custom api_extension_paths to neutron-api.
and not just when enable-l3ha is true. This is to provide non-ha environments
with the option to have multiple dhcp agents (which are controlled directly by
neutron). The default, is therefore, 1.
