Make octavia service_auth project configurable
(Renamed and adapted from Switch octavia to use service project in service_auth on master and stable/ussuri) Recently a patch [1] was merged to stop adding the octavia user to the admin project, and remove it on upgrade. However, the octavia configuration was not updated to use the service project, causing load balancer creation to fail. There is also an issue for existing deployments in simply switching to the service project. While existing load balancers appear to continue to work, creating new load balancers fails due to the security group belonging to the admin project. At a minimum, the deployer needs to create a security group in the service project, and update 'octavia_amp_secgroup_list' to match its ID. Ideally the flavor and network would also be recreated in the service project, although this does not seem to impact operation and will result in downtime for existing Amphorae. This change adds a new variable, 'octavia_service_auth_project', that can be used to set the project. The default in Ussuri is 'service', switching to the new behaviour. For backports of this patch to Train and earlier branches it should be switched to 'admin' to maintain compatibility. In Train and earlier, if a deployer keeps the default 'octavia_service_auth_project' of 'admin', the octavia user will be assigned the admin role in the admin project, as was done previously. They may also set 'octavia_service_auth_project' to 'service' to use the new behaviour, and avoid a breaking change when later upgrading to Ussuri. Closes-Bug: #1882643 Related-Bug: #1873176 [1] https://review.opendev.org/720243/ Co-Authored-By: Mark Goddard <mark@stackhpc.com> Change-Id: I1efd0154ebaee69373ae5bccd391ee9c68d09b30 (cherry picked from commitc2037885e7
) (cherry picked from commit1851d88126
)
This commit is contained in:
parent
f3ba8d5f23
commit
a0868027ff
|
@ -113,4 +113,8 @@ octavia_logging_debug: "{{ openstack_logging_debug }}"
|
|||
|
||||
octavia_keystone_user: "octavia"
|
||||
|
||||
# Project that Octavia will use to interact with other services. Note that in
|
||||
# Ussuri and later releases this will change to "service".
|
||||
octavia_service_auth_project: "admin"
|
||||
|
||||
openstack_octavia_auth: "{{ openstack_auth }}"
|
||||
|
|
|
@ -33,6 +33,20 @@
|
|||
endpoint_type: "{{ openstack_interface }}"
|
||||
run_once: True
|
||||
|
||||
- name: "Adding admin role to octavia user in {{ octavia_service_auth_project }} project"
|
||||
become: true
|
||||
kolla_toolbox:
|
||||
module_name: "os_user_role"
|
||||
module_args:
|
||||
user: "{{ octavia_keystone_user }}"
|
||||
role: admin
|
||||
project: "{{ octavia_service_auth_project }}"
|
||||
auth: "{{ openstack_octavia_auth }}"
|
||||
endpoint_type: "{{ openstack_interface }}"
|
||||
cacert: "{{ openstack_cacert }}"
|
||||
run_once: True
|
||||
when: octavia_service_auth_project != 'service'
|
||||
|
||||
- name: Adding octavia related roles
|
||||
become: true
|
||||
kolla_toolbox:
|
||||
|
|
|
@ -32,7 +32,7 @@ auth_type = password
|
|||
username = {{ octavia_keystone_user }}
|
||||
password = {{ octavia_keystone_password }}
|
||||
user_domain_name = {{ default_user_domain_name }}
|
||||
project_name = {{ openstack_auth.project_name }}
|
||||
project_name = {{ octavia_service_auth_project }}
|
||||
project_domain_name = {{ default_project_domain_name }}
|
||||
|
||||
memcache_security_strategy = ENCRYPT
|
||||
|
|
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
fixes:
|
||||
- |
|
||||
In the previous stable release, the octavia user was no longer given the
|
||||
admin role in the admin project, and a task was added to remove the role
|
||||
during upgrades. However, the octavia configuration was not updated to use
|
||||
the service project, causing load balancer creation to fail. See upgrade
|
||||
notes for details. `LP#1873176
|
||||
<https://bugs.launchpad.net/kolla-ansible/+bug/1873176>`__
|
||||
upgrade:
|
||||
- |
|
||||
In the previous stable release, the octavia user was no longer given the
|
||||
admin role in the admin project, and a task was added to remove the role
|
||||
during upgrades. However, the octavia configuration was not updated to use
|
||||
the service project, causing load balancer creation to fail.
|
||||
|
||||
There is also an issue for existing deployments in simply switching to the
|
||||
service project. While existing load balancers appear to continue to work,
|
||||
creating new load balancers fails due to the security group belonging to
|
||||
the admin project. For this reason, Train and Stein have been reverted to
|
||||
use the admin project by default, while from the Ussuri release the service
|
||||
project will be used by default.
|
||||
|
||||
To provide flexibility, an ``octavia_service_auth_project`` variable has
|
||||
been added. In the Train and Stein releases this is set to ``admin`` by
|
||||
default, and from Ussuri it will be set to ``service`` by default.
|
||||
For users of Train and Stein, ``octavia_service_auth_project`` may be set
|
||||
to ``service`` in order to avoid a breaking change during the Ussuri
|
||||
upgrade.
|
||||
|
||||
To switch an existing deployment from using the ``admin`` project to the
|
||||
``service`` project, it will at least be necessary to create the required
|
||||
security group in the ``service`` project, and update
|
||||
``octavia_amp_secgroup_list`` to this group's ID. Ideally the Amphora
|
||||
flavor and network would also be recreated in the ``service`` project,
|
||||
although this does not appear to be necessary for operation, and will
|
||||
impact existing Amphorae.
|
||||
|
||||
See `bug 1873176 <https://bugs.launchpad.net/kolla-ansible/+bug/1873176>`__
|
||||
for details.
|
Loading…
Reference in New Issue