Anything that needs a service catalog can get it directly from
auth_ref.service_catalog, no need to carry the extra attribute.
ClientManager.get_endpoint_for_service_type() reamins the proper
method to get an endpoint for clients that still need one directly.
Change-Id: I809091c9c71d08f29606d7fd8b500898ff2cb8ae
1) Can't create instance of swiftclient. Since we now create
an API instance, creating a swiftclient instance won't work.
Trying to do any object related command fails.
2) Listing objects in a container fails, we depend on the
data returned in a specific way, during the API transition
this must have slipped through.
Needs regression/funcitonal tests to mame sure this doesn't
happen again.
Change-Id: I69079a0dc9f32b84e6f9307729d3dbbba549ac5e
api.object_store.APIv1 now contains the formerly top-level functions
implementing the object-store REST client. This replaces the old-style
ObjectClientv1 that is no longer necessary.
Change-Id: I7d8fea326b214481e7d6b24119bd41777c6aa968
Previously the API_NAME was 'object-store' which caused all sorts
of failures when running swift commands
Change-Id: I448ca10f7d173024313722246e63cf23fd71117c
Closes-Bug: #1343658
Allows client libraries to have complete access to the rest of the
OSC ClientManager. In addition, extension libraries can define
global options (for API version options/env vars) and define
versioned API entry points similar to the in-repo commands.
The changes to ClientManager exposed some issues in the existing
object api tests that needed to be cleaned up.
Change-Id: Ic9662edf34c5dd130a2f1a69d2454adefc1f8a95
* Add object-store API to ClientManager
* Add object-store client
* Add Object API library in openstackclient.object.v1.lib
* Add Object API {container,object} list commands
* Add library tests
* Add command tests
This should complete the Object v1 container and object list commands
Change-Id: Ib1770d45efa8871959826b85faafa1e0bcef0a03