i18n library is present in openstack.common but we also have
glanceclient module that supports the same functionality.
In order to be consistent and exclude dependencies on
oslo-incubator code we need to use glanceclient.i18n module only.
Change-Id: Iae9722d7903034bfa6fb8afadbb1f1292c29203e
The latest change to the auth_required logic introduced a bug were even
when the token and endpoint were passed, authentication was being
required.
This patch fixes that issue and makes sure that authentication is not
required when these 2 arguements are present.
Closes-bug: #1499540
Change-Id: I4c9c15ba526378970da5461511ed922d42c5a9f9
Command help message uses help and CLI-Reference generation.
and in convention, help message stops with period ".".
Change-Id: I652afdb5e4d69a0476a0a2dc313ae60ece3b7bbc
The client currently downloads the image metadata to check if it's deleted
or not. This logic belongs to the server and it's already implemented
there. Instead of getting the image, send the delete request and catch
the 404 error, which is already raised by the server.
Change-Id: I1e6ef42340f8e380ff99b9d6ca7ea416e0eebfbc
Closes-bug: #1496305
f6712f5 Print the reverting back to v1 to stderr
2c7da7c Invalid output running the command 'glance image-show <image_id>'
5026774 Don't make `help` require auth parameters
75ec903 check for None value in utils.safe_header
f0b30f4 Updated from global requirements
1322fbc Consider `--os-token` when using v2
47423eb Check if v2 is available and fallback
90b7dc4 Update path to subunit2html in post_test_hook
1e2274a Password should be prompted once
Change-Id: I70329b9596421a4d8c0c953c19759a96f29c8b0d
If CLI client is called without any subcommands or arguments it will
fail with """'Namespace' object has no attribute 'command'""". This
is coming from the getattr which does not have alternate value
specified.
Closes-Bug: #1494259
Change-Id: I461f0d4a91f3af2224bafc14a88572a8e4a3c051
When querying against a Juno glance-registry, we found that having the
--sort option defaulting to 'name:asc" results in querying the registry
with additional SQL parameters like the following:
WHERE image_properties_2.name = :name_1 AND image_properties_2.value =
:value_1
as a result of handling the newer 'sort' filter. This results in a
blank list being returned as the output of glance image-list.
This patch sets the --sort-key and --sort-dir instead of --sort when
neither --sort-key nor --sort-dir are specified, so as to maintain
backwards compatibility with Juno glance-registry.
Change-Id: I8bd64cca7f1b7abdbabf4c09e3dbbcb4044e51b4
Closes-bug: #1492887
Running the command returns the string 'id' and fails on exception.
In function _image_meta_from_headers the meta variable was not properly
set because key was not lowercased. Converting key to lowercase solves
the problem.
NOTE: this is a compatibility fix for urllib3 >= 1.11
Closes-Bug: #1487645
Co-Authored-by: Flavio Percoco <flavio@redhat.com>
Change-Id: I1b0b327163577585becb5e762536058d21dc1c98
The `help` command was behaving a bit funky. This patch re-orders the
code a bit so that the `help` command will be parsed at the very
beginning before running other commands and checks.
It also allows to get help without downloading/checking schemas and
without requiring auth credentials (previously required by the schema
operations).
Change-Id: Ib7b10d4d80f15e6b75bb8644d7d916bef09413d6
Closes-bug: #1490457
Add parsing the endpoint URL and check the path string only
in order to decide the API version.
Change-Id: Ib0a035f3bed31e2162a1231a5f5dcc3907d37243
Closes-Bug: #1489727
In case that a sensetive header (that should be obscured by its SHA1
hash) is None, the safe_header throws an exception which fails the
calling process and by that may harm the functionality.
Change-Id: I56944a382fd546eba0a6dd6d6b1cecf83b1dc106
Closes-Bug: #1491311
The `_cache_schemas` call currently forces authentication even when the
`auth_token` and `os_image_url` are passed. Instead of handling forced
authentications, let the client use the passed arguments and
authenticate only once if needed.
This was not caught by the existing tests because the call to
`_cache_schemas` was mocked.
Change-Id: I93cec9a68cafc0992d14dab38114d03e25f1e5da
Closes-bug: #1490462
We have a basic implementation for a fallback mechanism that will use v1
rather than v2 when downloading schema files from glance-api fails.
However, this is not sound. If the schemas are cached already, we won't
check if v2 is available and fail to fallback.
This patch fixes the aforementioned issue by getting the list of
available versions from the server only when the API versions was not
explicitly specified through the CLI. That is, for all commands that
don't pass `--os-image-api-version 2`, we'll check v2's availability and
we'll fallback to v1 if it isn't available.
This patch also changes how we handle `/versions` calls in the client.
The server has been, incorrectly, replying to requests to `/version`
with a 300 error, which ended up in the client re-raising such
exception. While I think 300 shouldn't raise an exception, I think we
should handle that in a spearate patch. Therefore, this patch just
avoids raising such exception when `/version` is explicitly called.
This fallback behaviour and the check on `/versions` will be removed in
future versions of the client. The later depends on this bug[0] being
fixed.
[0] https://bugs.launchpad.net/glance/+bug/1491350
Closes-bug: #1489381
Change-Id: Ibeba6bc86db2a97b8a2b4bd042248464cd792e5e
The check used to verify if there are any properties to remove in the V2
image-update command will always execute even if there are no properties to
remove due to the fact that it checks if remove_prop is not None, when it is
actually a list and not a None value.
Closes-Bug: #1475053
Change-Id: Ia36e945b880de3514c73073a392bdb7dde13cf84
There's a corner case where password may be requested twice. In a fresh
environment, when schemas have not be downloaded for v2, the client will
ask for a password to download the schemas and then it'll ask for the
password again to run the actual command. This happens because we parse
the CLI arguments twice to make sure we're parsing them for the right
client version.
This patch checks if the password is unset in the newly parsed arguments
and if it's been set in the previously parsed ones. In this case it
keeps the set password. I believe this approach is safer than re-using
the already parsed arguements which may have been parsed for a different
API version (might happen because we fallback to v1 if v2 is not
available).
Change-Id: I080253170e3e84a90363e5bb494cf137895fe2e7
Closes-bug: #1488892
Custom SSL handling was introduced because disabling SSL layer compression
provided an approximately five fold performance increase in some
cases. Without SSL layer compression disabled the image transfer would be
CPU bound -- with the CPU performing the DEFLATE algorithm. This would
typically limit image transfers to < 20 MB/s. When --no-ssl-compression
was specified the client would not negotiate any compression algorithm
during the SSL handshake with the server which would remove the CPU
bottleneck and transfers could approach wire speed.
In order to support '--no-ssl-compression' two totally separate code
paths exist depending on whether this is True or False. When SSL
compression is disabled, rather than using the standard 'requests'
library, we enter some custom code based on pyopenssl and httplib in
order to disable compression.
This patch/spec proposes removing the custom code because:
* It is a burden to maintain
Eg adding new code such as keystone session support is more complicated
* It can introduce additional failure modes
We have seen some bugs related to the 'custom' certificate checking
* Newer Operating Systems disable SSL for us.
Eg. While Debian 7 defaulted to compression 'on', Debian 8 has compression
'off'. This makes both servers and client less likely to have compression
enabled.
* Newer combinations of 'requests' and 'python' do this for us
Requests disables compression when backed by a version of python which
supports it (>= 2.7.9). This makes clients more likely to disable
compression out-of-the-box.
* It is (in principle) possible to do this on older versions too
If pyopenssl, ndg-httpsclient and pyasn1 are installed on older
operating system/python combinations, the requests library should
disable SSL compression on the client side.
* Systems that have SSL compression enabled may be vulnerable to the CRIME
(https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4929) attack.
Installations which are security conscious should be running the Glance
server with SSL disabled.
Full Spec: https://review.openstack.org/#/c/187674
Blueprint: remove-custom-client-ssl-handling
Change-Id: I7e7761fc91b0d6da03939374eeedd809534f6edf
In v2, it's only show Id and Name. When use --verbose, although added
owner and status, it's still lack of Disk-format,Container-format and
Size.
Change-Id: I26b4b7bd3a3f6dbf82ca73c32dd94c56e8e173a1
Closes-bug:#1486329
Currently glanceclient doesn't enforce disk-format or container-format
presence in the command line on image-create when providing image data
(with --file, --location, --copy-from), which means that the POST
request is made with the whole image and error is reported by Glance
API.
This post enforces presence of those arguments when image data is
provided so we can get the error quicker and avoid sending unnecessary
data over the network.
Change-Id: I5914fa9cfef190a028b374005adbf3a804b1b677
Closes-Bug: #1309272
Now that we have stable branches for clients, it's easier to keep track
of the current default image's schema in Glance and update it
respectively. This patch adds the current image schema, including the
schema-properties.
One good reason to do this is to be able to react when a running Glance
instance is not around to be introspected. It's really unfortunate that
things like help text can't be rendered when there image schema is not
available in the system.
We could keep the schema in a json file but rather than shipping data
files with glanceclient we can just have it in the python modules.
Change-Id: I9b8cc1d18d6717ccf991fb8149ab13c06d653ee4
Closes-bug: #1481729
Now we have claimed v2 is the current API version of Glance,
we should change the Glance client as well to be consistent
with Glance server.
DocImpact
Change-Id: I09c9e409d149e2d797785591183e06c13229b7f7
Previously when listing images via v2, the first image of each batch
was validated against the v2 schema.
This could lead to unpredictable behaviour where a particular image
which failed the schema check may or may not be the first of a batch.
In some cases it also meant that operation by one user could affect the
ability of another other to list images.
Change-Id: I22974a3e3d9cbdd254099780752ae45ff2a557af
Closes-bug: 1477910
kairat_kushaev