Dashboard scenario test does not consider Horizon auth version

Bug #1531594 reported by Dan Nguyen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tempest
Fix Released
Undecided
Dan Nguyen

Bug Description

Desc:

The current tempest configs requires a new property for the version of Keystone that Horizon is set too. The log in screen will require a domain name when Horizon's local_settings.py is set to Keystone v3 with multi-domain support enabled.

Details:

The Keystone API runs both version 2 and version 3 concurrently.
They are not compatible and have different methods of authentication.

Clients can choose which version of the API to talk to. (i.e. choosing the endpoint)

Horizon (The OpenStack Dashboard) uses the Keystone Client binding to authenticate to the Keystone API. Too choose which version of the Keystone API to use there are settings in Horizon.

When Horizon's settings are configured to talk to the Keystone V3 API the login screen will require additional credentials. Namely the the domain name of the user. When this is omitted, authentication will fail. There user will not be able to login and view the Overview screen.

Tempest has a scenario test that assumes Horizon will be configured to use Keystone V2. This tests fails when Horizon is configured to use Keystone V3.

The Proposed Fix:

Add a new property to skip the test based on a config property for the auth_version that horizon is using. This approach is consistent with how Tempest handles skipping over tests.

Changed in tempest:
assignee: nobody → Dan Nguyen (daniel-a-nguyen)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to tempest (master)

Fix proposed to branch: master
Review: https://review.openstack.org/264354

Changed in tempest:
status: New → In Progress
Revision history for this message
Jordan Pittier (jordan-pittier) wrote :

What's the bug here ? How can I reproduce the issue ?

description: updated
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to tempest (master)

Reviewed: https://review.openstack.org/264354
Committed: https://git.openstack.org/cgit/openstack/tempest/commit/?id=a6aa1aa6d09583ecd71f2e0bcfee7dee74debad2
Submitter: Jenkins
Branch: master

commit a6aa1aa6d09583ecd71f2e0bcfee7dee74debad2
Author: daniel-a-nguyen <email address hidden>
Date: Wed Jan 6 13:15:21 2016 -0800

    Adds default domain name to dashboard login params

    Desc:

    The current tempest configs requires a new property for the version of
    Keystone that Horizon is set too. The login screen will require a
    domain name when Horizon's local_settings.py is set to Keystone v3 with
    multi-domain support enabled.

    Details:

    The Keystone API runs both version 2 and version 3 concurrently.
    They are not compatible and have different methods of authentication.

    Clients can choose which version of the API to talk to. (i.e. choosing
    the endpoint)

    Horizon (The OpenStack Dashboard) uses the Keystone Client binding to
    authenticate to the Keystone API. Too choose which version of the
    Keystone API to use there are settings in Horizon.

    When Horizon's settings are configured to talk to the Keystone V3 API
    the login screen will require additional credentials. Namely the the
    domain name of the user. When this is omitted, authentication will fail.
    The user will not be able to login and view the Overview screen.

    Tempest has a scenario test that assumes Horizon will be configured to
    use Keystone V2. This tests fails when Horizon is configured to use
    Keystone V3.

    The Proposed Fix:

    Pass an additional request param to the login form that will allow
    this scenario test to work for both keystone v2 and keystone v3.

    Closes-Bug: #1531594
    Change-Id: I060a7ceb19c2c2872b065c94d31255b0dc1750fc

Changed in tempest:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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