[openstack-qa] unversion endpoints in tempest
Frittoli, Andrea (Cloud Services)
frittoli at hp.com
Thu Jul 11 14:28:50 UTC 2013
Back on the topic of endpoints. last time I didn't get any feedback, and
unfortunately I missed the last few weekly meetings.
The change I proposed for devstack to have a computev3 endpoint is now
passing verification: https://review.openstack.org/#/c/33277/ so reviews
are welcome.
The nova API v3 tests depend on having this closed in either direction -
approved or irrevocably rejected.
If this change is approved nova API v3 test can use a computev3 endpoint as
it will be defined in devstack.
Else all tests will have to rely on a v3 endpoint mangled out of the v2 one.
In this case we should have the mangling function in some util method rather
than repeated in all clients.
andrea
From: Frittoli, Andrea (Cloud Services)
Sent: 25 June 2013 12:51
To: All Things QA.
Subject: [openstack-qa] unversion endpoints in tempest
There seem to be a general agreement towards having version independent
endpoints in the catalogue - see
http://lists.openstack.org/pipermail/openstack-dev/2013-May/008436.html.
As far as I know this is only at proposal stage, and it requires changes in
client libraries as well as in the services to be implemented. Therefore
need an ad-interim solution.
The current status in devstack is:
- Glance exposes an un-versioned endpoint already, and the tests
are able to discover the available API version.
- Keystone exposes a versioned endpoint. Querying the root of the
endpoint returns the available endpoints and versions.
- Compute exposes a versioned endpoint. Querying the root of the
endpoint returns the available endpoints and versions, but the endpoints
here do not include the context, as query to the root endpoint does not
require authentication.
Glance and keystone I wouldn't change.
For keystone we could however align to Glance on tempest side, by extracting
the root of the endpoint and querying it to check for available versions.
For the compute one I have a proposed change in devstack
(https://bugs.launchpad.net/devstack/+bug/1191798,
https://review.openstack.org/#/c/33277/), which adds a computev3 endpoint.
The alternative is to use the v2 URL and mangle it into a v3 one, like in
https://review.openstack.org/#/c/29703/13. If we go this way I'd like to
factor the code that creates the v3 endpoint into the rest_client.py (or a
new compute_v3_rest_client.py), so that it can be used by all the compute v3
clients.
Does anyone have a strong opinion on how we would like the devstack
endpoints to be and how the tempest clients should use them?
andrea
--
Andrea Frittoli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20130711/c313b04e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6202 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20130711/c313b04e/attachment-0001.bin>
More information about the openstack-qa
mailing list