When an existing cluster of the service is scaled out the new unit
will join with keystone before it is fully clustered. In identity
joined hook the charmhelpers function canonical_url is called which
in turn uses another charmhelpers function, resolve_address.
resolve_address will only return the vip if the vip is set in config
AND the unit is clustered. This means that the units local address
is returned and that is then registered with keystone.
This change gates registering an endpoint if the cluster is
partially formed.
Change-Id: I233e0cccb8ccd732080fd239df6d1e7db174eba5
Partial-Bug: #1544959
This patch adds the enable-qos option to the charm. If enable-qos is
set then neutron.services.qos.qos_plugin.QoSPlugin is added to
service_plugins in neutron.conf locally. The
neutron-plugin-api-relation has also been updated to send the
enable-qos option to charms connected over that relation (for
example neutron-openvswitch and neutron-gateway).
As part of this some of the logic for setting service_plugins was
removed from the neutron.conf and placed in the NeutronCCContext.
This patch is based on the steps in:
https://docs.openstack.org/mitaka/networking-guide/config-qos.html
Change-Id: I1beba9bebdb7766fd95d47bf13b6f4ad86e762b5
Partial-Bug: #1705358
Currently whenever the shared-db hook fires we call
migrate_neutron_database() which will always (unless unit
is paused) do a migration and restart the neutron-server
service. This is unnecessary and disruptive so we avoid
doing this by first checking whether we have already
initialised and and skipping migrate and restart if we
have already initialised. We also add support to override
this logic if an upgrade is in progress.
Change-Id: Ia4c104ff21d10a0d24ac3038bb75a5a9dc67ca94
Closes-Bug: 1708459
Enable dual stack IPv4 and IPv6 VIPs on the same interface.
HAProxy always listens on both IPv4 and IPv6 allowing connectivity
on either protocol.
charm-helpers sync for HAProxy template changes.
Change-Id: I4f011b404abb63e8b8e612a57f285010d06ccb0c
This patch adds support for setting polling-interval rpc-response-timeout
and report-interval in neutron-api charm centrally, then other charms
need to continue doing:
1, polling_interval
Just used by neutron l2 agents, so neutron-openvswitch charm
gets it via its 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 its 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 its relations and set it
in [agent] of neutron.conf
This patch also syncs charmhelpers.
Change-Id: I669e959a596b214acf486b0532c4ab31c2b82557
Partial-Bug: #1685788
Use the get_relation_ip function for selecting addresses for the
cluster relationship. Including overrides for the admin, internal,
and public config settings or extra bindings.
Change-Id: Ief31b5bf605e6fad0b5fc57cd048e3d8badfa2db
Partial-Bug: #1687439
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
When the percona-cluster charm sets an access-network but the default
unit-get address is not on that network extra shared-db relations get
executed. This is specifically a problem when running upgrades and
trying to avoid API downtime.
The root cause is that the access-network is not checked until the
SharedDBContext is consulted. But then db_joined function will
change it back to the wrong ip on subsequent runs.
This change adds a check for access-network on the relation during
the db_joined function and pushes IP selection off to get_relation_ip.
Charm helpers sync to pull in changes to get_relation_ip.
Partial-bug: #1677647
Change-Id: I20f35dd7a12315ef61939feb5199680db128bc0b
- 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
neutron-api was still using the old approach to status assessment,
calling the os_set_workload_status function rather than the provided
assess_status function in neutron_api_utils.
Switch to using assess_status, which also correctly sets the
application version for the application.
Change-Id: I324f6e77bca96f2bb0aacc286050ee258dd09f77
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
Implement DNS high availability. Pass the correct information to
hacluster to register a DNS entry with MAAS 2.0 or greater rather
than using a virtual IP.
Charm-helpers sync to bring in DNS HA helpers
Change-Id: Ifb27cc96b913f4fe315119477691936919684b62
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>
The neutron-server process performs the db migration on icehouse so
check the Openstack version before running it
Closes-Bug: 1571782
Change-Id: Ib9a57eea296a3116c69551c057f1cf9093ac93a8
To ensure that the charm presents the right IP address for
accessing the MySQL database over the shared-db relation,
ensure that any network space binding provided by the user
is preferred over the default of 'private-address'.
If network spaces is not supported (juju < 2.0), fallback to
using 'private-address'.
Change-Id: I8e70be47250c650e4b0135b0f2707f7eb1d46d1e
Earlier versions of the nova-cloud-controller charm controlled
upgrades of the neutron databases; this has now been dropped
from the nova-cloud-controller charm.
Drop logic around conditional migration related to OpenStack
releases and always migrate the neutron database, so long as
the unit is the lead unit.
Change-Id: I944621203e8f4a2337151f2d406fe0f2c7d1a71f
Add charmhelpers.contrib.hardening and calls to install,
config-changed, upgrade-charm and update-status hooks.
Also add new config option to allow one or more hardening
modules to be applied at runtime.
Change-Id: I46e1b43df3a5e59018f604ce1ae20bd62744a45b
Adds pause and resume unit to the charm such that the
charm stays paused during maintenance operations.
Partial-Bug: 1558642
Change-Id: Id5c44143f30305a3c412648cebb4c30caaa3e789
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.
