Comment 5 for bug 1882643

Reviewed: https://review.opendev.org/736315
Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=f81dcc8e963c7c4e9b833333022fd4cc21b3b19e
Submitter: Zuul
Branch: stable/ussuri

commit f81dcc8e963c7c4e9b833333022fd4cc21b3b19e
Author: Xing Zhang <email address hidden>
Date: Tue May 12 19:07:30 2020 +0800

    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 <email address hidden>

    Change-Id: I1efd0154ebaee69373ae5bccd391ee9c68d09b30
    (cherry picked from commit c2037885e756b4d42b38e1ce1852a50d2ffbc764)