Ensures that leader does not respond to db init
notifications to avoid infitinite looping after
leader switches to a different unit.
Also ensures that leader only restarts its neutron-server
once on db init.
Closes-Bug: #1893008
Change-Id: I59b9d5e0caab62b72380879bf16cb0fd8703bb32
The new default will take effect on newly deployed units when
openstack-origin is set to 'ussuri' or newer.
Any existing units or newly deployed units with openstack-origin
set to prior versions will retain the existing default.
Change-Id: Ia38dd7882105c3adad1afbf754ba2ed047dd05e2
When resuming services exclude those managed by hacluster, in
this case haproxy. If pacemaker lacks quorum it may shut haproxy
down which will cause this charm to error.
Charmhelper sync included to bring in required
get_managed_services_and_ports method.
Change-Id: Ie6f117f47a8189c8e30224f7200d8976cdec9605
Currently, Apache ports.conf file is not being configured by this
charm. This patch changes the ports.conf default file with another one
that does not open port 80 on SSL environments.
Change-Id: I0d935de2eada861b986e2f17ead6a5674afd2969
Closes-bug: #1845665
There are transient situations where the config option openstack-origin will
hold the target OpenStack version, so it's not safe to be used to determine
what packages should be installed in the unit, an accurate method is to use
the version of the neutron-common package.
Change-Id: I88693be390f66ba94626e52b949b5573532ea5d7
Closes-Bug: #1854538
This patch removes completely any lbaas related service or
configuration for OS Train deployements.
Change-Id: Ib48adee32d649e5254265924175c3bf2d3437c0b
Closes-Bug: #1853868
Signed-off-by: Stamatis Katsaounis <skatsaounis@admin.grnet.gr>
This patch applies validation on values ipv4-ptr-zone-prefix-size and
ipv6-ptr-zone-prefix-size to prevent users from choosing values not
supported by Neutron's Designate driver.
Change-Id: I6f2d5c9d1a3f16242263f11b1f999ab7ec3a4266
Signed-off-by: Stamatis Katsaounis <katsaouniss@gmail.com>
Drop install of python3-neutron-lbaas as this package has been
dropped from the UCA at Train.
Add test bundle for train; make smoke to validate changes.
Change-Id: I355a136a0ced7367d69ee9fb8c3b493ddae5e087
When a plugin does not override the ``core_plugin`` and
``neutron_plugin_config`` and leaves them to the ML2 default the
charm will now register the ``ml2_conf.ini`` config with both
the default Neutron and subordinate plugin contexts.
Any exposed context variables not provided by the plugin will no
longer be returned as empty values on the context, allowing for
passing of the Neutron API charm deduced and configured context
values.
The ``neutron.conf`` and ``ml2_conf.ini`` templates have been
updated to allow adding of new sections.
Partial-Bug: #1845212
Change-Id: I90ca77ad16c1a0f59deb34c4faa7e7a89f22aea9
We can't add constraints to admin role without consider
regressions. It happens that two tempest scenarios are now failling:
tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops
tempest.scenario.test_server_multinode.TestServerMultinode.test_schedule_to_all_nodes
If admin wants to give role (even Admin role) to an user for a tenant,
the right way is to use keystone trust API.
Change-Id: I161ea7d1aec5e5784455b5bce4605b2f9143daa2
Related-Bug: #1830536
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
When determining if a user is an admin the default neutron policy
file only checks if a user has the 'admin' role. It does not check
what that role is applied to.
The problem is illustrated by the following scenario: A cloud
admin creates a new domain, then creates a new project within that
domain. The cloud admin wants to delegate the maintenance of the
new project to userA so she grants them admin on the new project.
UserA is now a cloud admin from Neutrons pov.
To fix this issue a policy override file is added which checks that
the user is admin either against the admin project (as defined by
keystone) or the service project.
Change-Id: If4c5b0c1ab7bf2c75e911e77531d442d417a1231
Closes-Bug: 1830536
If the certificates change then services needs to
be restarted. This change adds the SSL directory to the restart map
to ensure any certificate changes trigger a restart.
Change-Id: I891b3104c08c6b9cde06ce30d4279a239ae329b1
Closes-Bug: 1828530
Ensure that the firewall v1->v2 migrate tool is executed post
upgrade to stein or later.
Fix minor issue with switch of default mysql dialect to mysqldb
at Stein by writing all new configuration files prior to
executing the database upgrade.
Change-Id: Ifb0b33038a4df7a2a6f5c1a55caaeea01a92fc20
Closes-Bug: 1821192
Switch neutron installation to use Python 3 for OpenStack Rocky.
Purge python- packages on upgrade.
Fix duplicate keystone entry in api-paste.ini for Rocky.
Change-Id: I9ead4d0b637f3067e0aa9a20604b2738221860df
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: I44f00afeee8623713055310b025f1e91af18b86a
Updates across the charm and unit tests to switch to
execution under Python 3.
Note that the changes are not backwards compatible
with Python 2.
Refactor use of neutronclient python module to simply
wrap the neutron binary, using the yaml output format
to avoid the requirement for a Python 3 module on
older OpenStack release versions.
Change-Id: Ic26b0dd19a76552481939325963a6c21585dee3c
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
- 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
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: I33cce8efc03f9217552234a8e03133d360ce95e3
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
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: I45757fcd52426369b42916ad2195d2fe2f6a4c15
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
This change fixes the obvious race for a status_set() between
check_optional_interfaces() and assess_status() as the later calls the former
which calls status_set(), returns the status, which is then potentially set
again by the assess_status() function. This cleans up the code so that only a
single status_set() is performed when calling assess_status().
Change-Id: Ic5d0be6e1f7a2283e4dd0594c6465a99497dbbec
Related-Bug:#1588462
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
- Stable PPA source for Liberty onwards
- New neutron.conf for Liberty without dhcp_agents_per_network = 1000
- Testing for PPA source
Change-Id: I6ebee0ac3704a56f31ffbd48206360a3f0ba267a
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.
