From c2037885e756b4d42b38e1ce1852a50d2ffbc764 Mon Sep 17 00:00:00 2001 From: Xing Zhang Date: Tue, 12 May 2020 19:07:30 +0800 Subject: [PATCH] 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 Change-Id: I1efd0154ebaee69373ae5bccd391ee9c68d09b30 --- ansible/roles/octavia/defaults/main.yml | 4 ++++ ansible/roles/octavia/tasks/register.yml | 14 ++++++++++++++ .../roles/octavia/templates/octavia.conf.j2 | 2 +- ...admin-project-action-95c87ca45a1188d6.yaml | 19 ++++++++++++++++--- 4 files changed, 35 insertions(+), 4 deletions(-) diff --git a/ansible/roles/octavia/defaults/main.yml b/ansible/roles/octavia/defaults/main.yml index e0b04d5477..0e03c02665 100644 --- a/ansible/roles/octavia/defaults/main.yml +++ b/ansible/roles/octavia/defaults/main.yml @@ -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 }}" #################### diff --git a/ansible/roles/octavia/tasks/register.yml b/ansible/roles/octavia/tasks/register.yml index 39a0bc577b..a2e75d4698 100644 --- a/ansible/roles/octavia/tasks/register.yml +++ b/ansible/roles/octavia/tasks/register.yml @@ -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: diff --git a/ansible/roles/octavia/templates/octavia.conf.j2 b/ansible/roles/octavia/templates/octavia.conf.j2 index 128c695d43..d59e1cd02f 100644 --- a/ansible/roles/octavia/templates/octavia.conf.j2 +++ b/ansible/roles/octavia/templates/octavia.conf.j2 @@ -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 }} diff --git a/releasenotes/notes/remove-octavia-user-in-admin-project-action-95c87ca45a1188d6.yaml b/releasenotes/notes/remove-octavia-user-in-admin-project-action-95c87ca45a1188d6.yaml index 63b69524f3..0c7bfde5aa 100644 --- a/releasenotes/notes/remove-octavia-user-in-admin-project-action-95c87ca45a1188d6.yaml +++ b/releasenotes/notes/remove-octavia-user-in-admin-project-action-95c87ca45a1188d6.yaml @@ -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 `__ + 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 `__ for details.