Pass the subcomand's arguments instead of the base ones to the endpoint
creation call when quering the `/versions` endpoint. Passing the wrong
arguments will end in the auth_requirement not being identified and an
error 'Expected Endpoint' will be raised as no endpoint will be gotten
from keystone.
This patch also removes an unnecessary mock in the test code related to
this fix.
Depends-On Iefeb9bc123f8c65fecd0cba585ecd3eb349b23a6
Change-Id: I46088130b9175798e3719e43f48dc474fbc8a251
Closes-bug: #1504058
It turns out the server does not support this, and the underlying
code gets very unhappy.
Co-Authored-By:Itisha <ishadewan07@gmail.com>
Change-Id: If67c11da28adbb2d793430d122e3930cc278737f
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
Dictionary creation could be rewritten as a dictionary literal.
for example:
expect_namespace = {}
expect_namespace['namespace'] = 'MyNamespace'
expect_namespace['protected'] = True
could be rewritten as
expect_namespace = {
'namespace': 'MyNamespace',
'protected': True
}
TrivialFix
Change-Id: I76265c26861916ed01cadb62e9201aa871183566
The oslo.utils function has exception_to_unicode that can
replace glance util function exception_to_str.
So we don't to have this exception_to_str function in glance
anymore.
Change-Id: I332bc55558087920fdd6ae2d822bece5166f5ba6
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
Jenkins