nova tests dependent on specific ordering of services in keystone catalog

Bug #911528 reported by Adam Gandelman
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
Adam Gandelman

Bug Description


Taking a first crack at running Tempest tests against a multinode cluster deployed using Juju. Running the first test in the suite was failing. After authenticating with Keystone, it seems the rest_client is making the assumption that the first row in the services table is the always the nova endpoint:

      if resp.status == 200:
                auth_data = json.loads(body)['access']
                token = auth_data['token']['id']
                endpoints = auth_data['serviceCatalog'][0]['endpoints']
                mgmt_url = endpoints[0]['publicURL']

While it looks like devstack always configures the service catalog in this fashion (devstack/files/, it would be better if Tempest's REST client was able to locate the appropriate endpoint among many endpoints regardless of what order they were added to the catalog. This is especially true when using Juju (and presumably other orchestration tools), as the order that services are added to the catalog is largely dependent on how each machine takes to be provisioned, services configured, etc.

It also appears that the rest_client is currently only expected to be used for nova endpoints. If we wish to later smoke test glance, swift, etc. directly, perhaps the client library should be expanded to be a bit more flexible?

Daryl Walleck (dwalleck)
Changed in tempest:
importance: Undecided → High
assignee: nobody → Daryl Walleck (dwalleck)
Revision history for this message
Adam Gandelman (gandelman-a) wrote :

Hi Daryl-

I've fixed up a patch @ , refreshing my Gerrit-fu. It should be up for review shortly.

The change adds a bit more flexibility to the rest client library as it allows filtering endpoints from the service catalog by name. Current services/nova/ now attempt to query the 'nova' endpoint when instantiated, raising an exception if it can find none.

It still makes a similar assumption about only a single endpoint template being associated with a named service, but since I'm unsure of the expected behavior in this scenario (both in terms of testing/tempest and nova+keystone in general) perhaps we can cross that bridge when we begin testing those deployments.

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

Fix proposed to branch: master

Changed in tempest:
status: New → In Progress
Jay Pipes (jaypipes)
Changed in tempest:
assignee: Daryl Walleck (dwalleck) → Adam Gandelman (gandelman-a)
milestone: none → essex-3
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to tempest (master)

Submitter: Jenkins
Branch: master

commit e2d46b48ef7ff0f89fa6b385c602f65bc6a37c37
Author: Adam Gandelman <email address hidden>
Date: Tue Jan 3 17:40:44 2012 -0800

    RestClient to target specific services in Keystone catalog

    Previously, the rest client had no notion of specific services
    other than nova, since that is all the current tests cover. It
    also assumed the first row in the was the service
    that provides the nova endpoint. This change allows the RestClient
    to target specific services in the keystone catalog by name. Current
    nova services are updated to find the nova endpoint. Future services
    that hit glance or swift directly can make use of this as well.

    Cleanup pep8 in

    Fixes bug 911528

    Change-Id: I4d885d96a1d360021b4c8f6aa562f863c6df3608

Changed in tempest:
status: In Progress → Fix Committed
Jay Pipes (jaypipes)
Changed in tempest:
status: Fix Committed → Fix Released
Sean Dague (sdague)
Changed in tempest:
milestone: none → havana-3
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.