IETF RFC 3986 classifies "~" as a reserved character [1],
however until python3.7 [2], python's url parsing
used to encode this character.
urllib has seen a lot of churn in various python
releases, and hence we were using a six wrapper
to shield ourselves, however, this backwards-incompatible
change in encoding norms forces us to deal with
the problem at our end.
Manila's API accepts "~" in both, its encoded
or un-encoded forms. So, let's stop encoding it
within manilaclient, regardless of the version
of python running it.
[1] https://tools.ietf.org/html/rfc3986.html
[2] https://docs.python.org/3/library/urllib.parse.html#url-quoting
Closes-Bug: #1785283
Change-Id: I6df5d543ae94ed1fa966c8019a52e9fca19e387e
When using the name or description to filter the share group list,
if the name or description is unicode symbols, the query will fail
due to the invalid str value. This change is to fix this.
PS: this bug is left from [1]
[1] I73ed2b675542d3aeedc9efdba08067819bf7d3e4
Change-Id: I14db19fb87da5cac86ec3634ddde6d647999db96
Closes-bug: #1712988
In patch I96339778fa69c379863078250d5dfa7172f2c1b2, it called
self.list with search_opts, but some subclasses of ManagerWithFind
do not have search_opts in function list, this make some list
functions and show by name functions fail and throw 'unexpected
keyword argument search_opts' error. This patch will fix it.
Change-Id: Ic4b65c0e5900a0e3e19155d5d9d42d5063c3137d
Closes-Bug: #1738917
Closes-Bug: #1738918
Currently, when using admin context to execute 'manila
show <share-name>' to show a share detail which is not
owned by admin, it always fails with 'No share with a
name or ID of <share-name> exists'. This patch will fix
it.
Change-Id: I96339778fa69c379863078250d5dfa7172f2c1b2
Closes-Bug: #1721787
Manila needs a grouping construct that, like shares, is a 1st-class
atomic data type. Our experience with CGs has demonstrated the
complexity of adding a grouping capability, yet there are other use
cases such as migration, replication, and backup in which some
storage controllers could only offer such features on share groups.
CGs also highlighted the poor optics of an advanced feature with
comparatively little potential for vendor support. And adding new
grouping constructs for each new feature is not technically
feasible. All of the above may be addressed by generic groups,
which we think is a clean extension to the original architecture of
Manila.
Implements: blueprint manila-share-groups
Change-Id: I8e29baed62355fc31caeec9c7a66eaebfcbdf184
The Oslo team has moved all previously incubated code from the
openstack/oslo-incubator repository into separate library repositories
and released those libraries to the Python Package Index. Many of our
big tent project teams are still using the old, unsupported, incubated
versions of the code. The Oslo team has been working to remove that
incubated code from projects, and the time has come to finish that work.
As one of community-wide goals in Ocata, please see:
https://github.com/openstack/governance/blob/master/goals/ocata/remove-incubated-oslo-code.rst
Note: This commit also fix pep8 violations.
Change-Id: I03288adb94c702d1d63df88ef9ba33a2ff59eaa3
For the moment we cannot use experimental APIs using "python" client.
It is possible only if we use shell client (CLI).
It means, we cannot use "share replication", "share migration" and
"consistency groups" APIs of python manilaclient from other apps
such as Manila UI. So, add special experimental header on python
client level instead of CLI.
Change-Id: I6eed5dcfd1cb309817e083856b40e10cc6f970f6
Closes-Bug: #1599586
Some env var names (the vars starting with manilaclient_) are mixing
lower and uppercase. To be consistent with the other env vars (and
also with env vars from other openstack client projects), add also
the only-upper-case var names. Newly added env variables are:
- MANILACLIENT_UUID_CACHE_DIR
- MANILACLIENT_DEBUG
- MANILACLIENT_INSECURE
Closes-bug: #1535284
Change-Id: Ifd43c6d226487d2b1c4ec099096595373725e596
The Manila client needs the following changes to support microversions:
* Maintain backwards compatibility with Kilo. When the client detects
that the server doesn't support microversions it will fall back to
using the v1 API.
* The --os-share-api-version option supports overriding the version.
* If 1.0 is specified as the version the client will load the v1
client and use the server's v1 API.
* The client will send a request for the server's API version and
determine if the client's supported versions and the server's
supported versions overlap. If not the client will display an error
and quit. See diagram 1 below.
* The client supports the @wraps annotation. The annotation is used
with the v2/shell.py commands and any class that inherits from
the Manager class in manilaclient/base.py.
* If an appropriate command version isn't found for commands using
@wraps then the client will display an error and quit.
following commit: ab49d645befd04c84272f0d24e1b604012d191dd.
Diagram 1:
Client:
2.5 2.8
|-------------|
Server1:
2.0 2.5
|-------------|
Client uses version 2.5
Server2:
2.7 2.10
|-------------|
Client uses version 2.8
Server3:
2.9 2.12
|-------------|
Client displays error and quits
Server4:
1.0 (Kilo Server)
|-|
Client detects pre-microversion server and loads v1 client
Example usage of wraps annotation:
* Support 2.0 - 2.4: @api_versions.wraps("2.0", "2.4")
* Support 2.5 - latest: @api_versions.wraps("2.5")
Implements: blueprint manila-client-advanced-microversion-support
Change-Id: I3733fe85424e39566addc070d42609e508259f19
Manila client needs to provide 'X-Openstack-Manila-Api-Version' in the
HTTP request header along with the appropriate version. Manila client
also needs to provide 'X-OpenStack-Manila-API-Experimental' in the HTTP
request header for APIs that are marked as experimental. This is a
temporary fix until Manila client can support Nova style microversions.
Closes-bug: #1489450
Change-Id: I6344dfa6d272f0e813a4873c015be614ebeb4e7e
Remove functions 'arg', 'env' and 'add_arg' from
manilaclient.utils and use same functions from cliutils instead.
Partially implements: blueprint use-common-code
Change-Id: Ib41250d527c5949cdfb7c6956703ff4b371a062b
Replace own implementation of 'Resource' class with
same one from common apiclient code.
Partially implements: blueprint use-common-code
Change-Id: I87ac06931a23721fc8cc2d58b5a9473618073f32
Delete own implementation of 'getid' func and
use same one from common apiclient code.
Partially implements: blueprint use-common-code
Change-Id: I833def921aaf105740e429453ee6b017012e7303
The bash completion code is the sole user of the slugify() function
in utils, which is substantially similar to to_slug() provided in
strutils from oslo. Remove slugify() and use to_slug() instead.
Change-Id: Iffab2f59504ee7ec6528860e06a5140ff22f332f
Closes-Bug: #1266127
Added detail parameter to list methods for security_services
and share_networks in v1.
Closes-bug #1297824
Change-Id: Iac2384bbf69c18f75291cc58509e8e99d0ac93ff
Added new keys '--user' in v1.shell to quota-show, quota-update.
Added command quota-delete, that provides ability for admins
to be able to delete a non-default quota (absolute limit) for a tenant
or user, so that tenant's quota will revert back to the configured default.
Added 'responce_key' parameter to Manager._update function
Added '--force' parameter to quota-update to support new functionality
on server
Fixes help output, when in 'manila help' was displayed only first
string of command documentation
Implement bp: user-quota-support
Change-Id: Ibfe9ccf83ea43d5af6652342f1fe6a88c78a0364
