Convert to using ClientManager and OpenStackShell from osc-lib.
* Change all internal uses of ClientManager private attributes that are
now public in osc-lib's ClientManager. Leave back-compat copies in
place in OSC's clientManager so we don't break plugins.
* Put some work-arounds in place for changes in osc-lib that we need until
a new release makes it through the g-r and u-c change process.
* Add a test for Unicode decoding of argv in shell.main() to parallel
the one in osc-lib.
Change-Id: I85289740d4ca081f2aca8c9b40ec422ad25d302c
Setting default versions in parsed args makes it so OCC
cannot tell if the argument was parsed, an environment
variable was set or it is just defaulted. In order to
set api versions from OCC, it will have to be defaulted
after processing OCC.
Closes-Bug: #1453229
Change-Id: I4d065919397b783f3bdd4022c986c0234a7a16e6
User should be able to specify the endpoint type through
a CLI optional argument/ENV variable setting. We will name this new
optional argument: --os-endpoint-type (Env: OS_ENDPOINT_TYPE) and
based on the value given, the service API will use that specific
endpoint type. Possible values: public, admin, internal.
DocImpact
Closes-Bug: #1454392
Change-Id: Ife3d4e46b44c0ddcd712b1130e27e362545a9a29
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