octavia user should't in admin project

[Xing Zhang]

For historic reasons, kolla-ansible deploy octavia by using admin credentials, add change to octavia user in patch [0] but adding a task for adding octavia user to admin project with admin role.

From octavia docs[1][2] and devstack[3], octavia project does not require octavia user in admin project, which is also acts like other projects, use a user in service project with admin role.

[0] https://github.com/openstack/kolla-ansible/commit/b7bfe84a515452d0f912a2f62392d22af17cd1d5#diff-b22aed7e666ae6cd5e9999ad34d0c817
[1] https://docs.openstack.org/octavia/latest/install/install-ubuntu.html
[2] https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html#production-deployment-walkthrough
[3] https://github.com/openstack/octavia/blob/master/devstack/plugin.sh

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/720243
Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=bb7e1e86601d46d1d12620ec44993c493bb923fe
Submitter: Zuul
Branch: master

commit bb7e1e86601d46d1d12620ec44993c493bb923fe
Author: Xing Zhang <email address hidden>
Date: Thu Apr 16 00:48:09 2020 +0800

    Remove octavia user from admin project

    It is unnecessary to add octavia user into admin project.
    Octavia project does not require this action. Like other projects,
    octavia user in service project with admin role is enough.

    [1] https://docs.openstack.org/octavia/latest/install/install-ubuntu.html
    [2] https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html#production-deployment-walkthrough
    [3] https://github.com/openstack/octavia/blob/master/devstack/plugin.sh

    Closes-Bug: #1873176
    Change-Id: I35d35177aaabfc6f0abc533a1f756b363bd02308

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/train
Review: https://review.opendev.org/723257

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/723259

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/723259
Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=4df06522455357dc320f251b4fbed79b171f9465
Submitter: Zuul
Branch: stable/stein

commit 4df06522455357dc320f251b4fbed79b171f9465
Author: Xing Zhang <email address hidden>
Date: Thu Apr 16 00:48:09 2020 +0800

    Remove octavia user from admin project

    It is unnecessary to add octavia user into admin project.
    Octavia project does not require this action. Like other projects,
    octavia user in service project with admin role is enough.

    [1] https://docs.openstack.org/octavia/latest/install/install-ubuntu.html
    [2] https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html#production-deployment-walkthrough
    [3] https://github.com/openstack/octavia/blob/master/devstack/plugin.sh

    Closes-Bug: #1873176
    Change-Id: I35d35177aaabfc6f0abc533a1f756b363bd02308
    (cherry picked from commit bb7e1e86601d46d1d12620ec44993c493bb923fe)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/723257
Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=07c89ac47f5cce41d3b1b17f68c3fc11bff18540
Submitter: Zuul
Branch: stable/train

commit 07c89ac47f5cce41d3b1b17f68c3fc11bff18540
Author: Xing Zhang <email address hidden>
Date: Thu Apr 16 00:48:09 2020 +0800

    Remove octavia user from admin project

    It is unnecessary to add octavia user into admin project.
    Octavia project does not require this action. Like other projects,
    octavia user in service project with admin role is enough.

    [1] https://docs.openstack.org/octavia/latest/install/install-ubuntu.html
    [2] https://docs.openstack.org/octavia/latest/contributor/guides/dev-quick-start.html#production-deployment-walkthrough
    [3] https://github.com/openstack/octavia/blob/master/devstack/plugin.sh

    Closes-Bug: #1873176
    Change-Id: I35d35177aaabfc6f0abc533a1f756b363bd02308
    (cherry picked from commit bb7e1e86601d46d1d12620ec44993c493bb923fe)

[Mark Goddard (mgoddard)]

Looking at the Octavia config, it seems it is configured to use the admin project, and the above change did not account for that.

https://opendev.org/openstack/kolla-ansible/src/commit/a5c1d366264ecfb60ac2a1e6b0c63278a9947010/ansible/roles/octavia/templates/octavia.conf.j2#L36

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/727160

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/727160
Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=c2037885e756b4d42b38e1ce1852a50d2ffbc764
Submitter: Zuul
Branch: master

commit c2037885e756b4d42b38e1ce1852a50d2ffbc764
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

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/736315

[OpenStack Infra (hudson-openstack)]

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)

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/train
Review: https://review.opendev.org/736591

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/736591
Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=1851d881261bc07f0f40179e427fd5f0e9c5a0ab
Submitter: Zuul
Branch: stable/train

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

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

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

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/stein
Review: https://review.opendev.org/737970

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/737970
Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=a0868027ff02b973d13daaa0700e5601ceb82a0a
Submitter: Zuul
Branch: stable/stein

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

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

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