kolla-ansible

octavia create loadbalancer failed due service_auth

  1. Series stein
  2. Bug #1882643
Bug #1882643 reported by wu.chunyang
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kolla-ansible
Fix Released
High
Mark Goddard
kolla-ansible 11.0.0 "victoria"
Stein
Fix Committed
High
Radosław Piliszek
Train
Fix Committed
High
Mark Goddard
Ussuri
Fix Released
High
Mark Goddard
kolla-ansible 10.0.0 "ussuri"
Victoria
Fix Released
High
Mark Goddard
kolla-ansible 11.0.0 "victoria"

Bug Description

i have configured octavia with kolla manual.
but when create loadbalancer it raises an eroor.

(openstack) loadbalancer create --vip-network-id 92ac19a4-4241-40fc-8baf-1d9f4c3e0838
The request you have made requires authentication. (HTTP 401) (Request-ID: req-8e2f5af7-a3df-40a1-a76e-ac075a6bc8c1) (HTTP 500) (Request-ID: req-1bcad1c2-af18-454a-85fc-3c3c772f66b7)

it is because octavia use has removed from admin project.[1]

octavia use service_auth section config to create neutroncleint[2],and the session paramers is here[3]

related bug: https://bugs.launchpad.net/kolla-ansible/+bug/1877417

[1]https://github.com/openstack/kolla-ansible/commit/bb7e1e86601d46d1d12620ec44993c493bb923fe#diff-181d068b5d48763becb2e4c0407ad95c
[2]https://github.com/openstack/octavia/blob/master/octavia/common/clients.py#L76
[3]https://github.com/openstack/octavia/blob/master/octavia/common/keystone.py#L28

solution:
1. like devstack, use admin user in service_auth section
2. add octavia to admin project(but we have remove it)

wu.chunyang (wuchunyang)
Changed in kolla-ansible:
assignee: nobody → wu.chunyang (wuchunyang)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to kolla-ansible (master)

Fix proposed to branch: master
Review: https://review.opendev.org/734435

Changed in kolla-ansible:
status: New → In Progress
Mark Goddard (mgoddard)
summary: - octavia create loadbalancer failed
+ octavia create loadbalancer failed due service_auth
OpenStack Infra (hudson-openstack)
Changed in kolla-ansible:
assignee: wu.chunyang (wuchunyang) → Mark Goddard (mgoddard)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on kolla-ansible (master)

Change abandoned by Radosław Piliszek (<email address hidden>) on branch: master
Review: https://review.opendev.org/734435
Reason: I'm abandoning this as we decided on the alternative

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to kolla-ansible (master)

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

Changed in kolla-ansible:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to kolla-ansible (stable/ussuri)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to kolla-ansible (stable/ussuri)

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)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to kolla-ansible (stable/train)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to kolla-ansible (stable/train)

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)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to kolla-ansible (stable/stein)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to kolla-ansible (stable/stein)

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)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.