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:
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/keystone_data.sh), 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?
Hi Daryl-
I've fixed up a patch @ http://
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.