Switch octavia to use service project in service_auth

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 it should be
switched to 'admin' to maintain compatibility.

If a deployer sets 'octavia_service_auth_project' to 'admin', the
octavia user will be assigned the admin role in the admin project, as
was done previously.

Closes-Bug: #1882643
Related-Bug: #1873176

[1] https://review.opendev.org/720243/

Co-Authored-By: Mark Goddard <mark@stackhpc.com>

Change-Id: I1efd0154ebaee69373ae5bccd391ee9c68d09b30
This commit is contained in:
Xing Zhang 2020-05-12 19:07:30 +08:00 committed by Mark Goddard
parent 12ac15b5f7
commit c2037885e7
4 changed files with 35 additions and 4 deletions

View File

@ -123,6 +123,10 @@ octavia_logging_debug: "{{ openstack_logging_debug }}"
octavia_keystone_user: "octavia"
# Project that Octavia will use to interact with other services. Note that in
# Train and earlier releases this was "admin".
octavia_service_auth_project: "service"
openstack_octavia_auth: "{{ openstack_auth }}"
####################

View File

@ -7,6 +7,20 @@
service_ks_register_users: "{{ octavia_ks_users }}"
tags: always
- 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:

View File

@ -33,7 +33,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 }}
cafile = {{ openstack_cacert }}

View File

@ -3,7 +3,20 @@ upgrade:
- |
The octavia user is no longer given the admin role in the admin
project. Octavia does not require this role and instead uses octavia
user with admin role in service project. During an upgrade the octavia
user is removed from the admin project. See
`bug 1873176 <https://bugs.launchpad.net/kolla-ansible/+bug/1873176>`__
user with admin role in service project. During an upgrade the octavia user
is removed from the admin project.
For existing deployments this may cause problems, so a
``octavia_service_auth_project`` variable has been added which may be set
to ``admin`` to return to the previous behaviour.
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.