nova tests dependent on specific ordering of services in keystone catalog
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tempest |
Fix Released
|
High
|
Adam Gandelman |
Bug Description
Hi-
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:
try:
While it looks like devstack always configures the service catalog in this fashion (devstack/
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?
Changed in tempest: | |
importance: | Undecided → High |
assignee: | nobody → Daryl Walleck (dwalleck) |
Changed in tempest: | |
assignee: | Daryl Walleck (dwalleck) → Adam Gandelman (gandelman-a) |
milestone: | none → essex-3 |
Changed in tempest: | |
status: | Fix Committed → Fix Released |
Changed in tempest: | |
milestone: | none → havana-3 |
Hi Daryl-
I've fixed up a patch @ http:// paste.ubuntu. com/792310/ , 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.