This code enables new syntax for sorting output with multiple
keys and directions based on API Working group sorting
guidelines.
It's a client code to consume API modified in change
Ie4ccfefa0492a3ac94cc7e22201f2f2be5c1cdbb
Example:
glance --os-image-api-version 2 --sort name:desc,size:asc
Implements-blueprint: glance-sorting-enhancements
DocImpact
Depends-On: Ie4ccfefa0492a3ac94cc7e22201f2f2be5c1cdbb
Change-Id: I36a9fa9f0508fea1235de2ac3a0d6a093e1af635
Currently, glanceclient.v2.update builds a patch request that does not
match glance API.
This patch overrides the default behaviour to customize the patch
request with the right format for the API.
Co-Authored-By: Steve Lewis <steve.lewis@rackspace.com>
Fixes bug 1306774
Change-Id: If0739ac285da1e741bfa40b6c719331a5ce49319
Previously this was read from the --page-size argument, which lead to
incorrect behaviour.
Change-Id: I08ecda95eca0ff524e28a1d5371ce6c73dfc548e
Closes-Bug: #1429088
This fixes the same problem with leaking file descriptors after the port
to requests I16a7b02f2b10e506e91719712cf34ef0aea1afc0 does, but for the
v2 api client.
The paginate function in the list method has been refactored from a
recursive generator to a non-recursive generator, which avoids issues
with garbage collection holding the socket open.
Change-Id: Iaa7a421e8c1acafb7b23bb3f55e50b9d2a9d030a
Closes-Bug: #1428797
os.path.isfile checks for existance anyway so
there is no point in checking both isfile and exists
Change-Id: Idbc2d22a807d5413db6e27ff0f6b5a87a5af8fa3
Deleting an already deleted image using admin user is throwing an
error "404 Not Found" which is confusing. Deleting an image that does
not exist throws "No image with a name or ID of 'image-id' exists."
Updated the code so that trying to delete an already deleted image
throws "No image with an ID of 'image-id' exists." error.
Closes-Bug: #1333119
Change-Id: I8f9a6174663337a0f48aafa029a4339c32eb2134
Co-Authored-By: Abhishek Talwar <abhishek.talwar@tcs.com>
Co-Authored-By: Kamil Rykowski <kamil.rykowski@intel.com>
The oslo.utils libraries are moving away from namespace packages.
This requires oslo.utils>=1.2.0
bp drop-namespace-packages
Change-Id: I803df61e91eabb96329d859aef6bea03530fb84f
In v2, we use the link header during paginations to know when there are
more images available in the server that could be returned in the same
request. This way, it's possible to iterate over the generator returned
by list and consume the images in the server.
However, it's currently not possible to tell glanceclient the exact
number of images we want, which basically means that it'll *always* go
through the whole list of images in the server unless the limit is
implemented by the consumer.
DocImpact
Change-Id: I9f65a40d4eafda6320e5c7d94d03fcd1bbc93e33
Closes-bug: #1415035
This module now lives in oslo.utils, so import it from there instead.
Co-Authored-By: Ian Cordasco <ian.cordasco@rackspace.com>
Change-Id: Ib35dc840992433542490670781badd9529ec8947
For example:
$ glance --os-image-api-version 2 image-create < /tmp/data
This is consistent with v1.
DocImpact
Closes-bug: 1408033
Change-Id: Ifed4ece9e4e02a46d80b49a8e4fc372f1a304241
Help for 'v2 image create --file' should refer to upload,
not download.
DocImpact
Change-Id: I2ae00e3242fb10001e216cde93fdf9c6f18ad13e
Closes-bug: 1408028
Previously, running:
cat something.img | glance image-create --progress --container-format=bare --disk-format=raw
or
cat something.img | glance --os-image-api-version 2 image-upload --progress <image id>
would result in an error. This error was caused by the length of the
input being unknown, so the overall progress cannot be found.
This patch disables the progress bar whenever the size of the input file
cannot be determined.
Change-Id: I6bfef7441864b638194126880241cc2c96d5b18b
Closes-Bug: #1402746
The move to the requests library (dbb242b) broke the progress bar during
downloading an image with --progress enabled, due to requests returning
a generator, which has no __len__ function. This patch adds an iterable
wrapper which provides the length, sourced from Content-Length headers.
Closes-Bug: #1384664
Change-Id: I48598a824396bc6e7cba69eb3ce32e7c8f30a18a
The rest api metadefs/namespaces supports pagination using the parameters
of limit, marker, sort_dir, & sort_key. However, the glance client isn't
passing those parameters through (they come in as kwargs). This is
preventing pagination from working properly in horizon.
This is affecting Horizon support: https://review.openstack.org/#/c/104063/
Change-Id: Ib349cf3a3a437eb1711f350b37d0bd0e7d01330a
Closes-Bug: 1381816
We currently require a version to always be passed to discover the
client version that should be loaded. However, this information is
commonly present in the URL instead. The current behavior forces
consumers of the library to keep the required version around and/or to
strip it themselves from the URL.
This patch relaxes that requirement by making the version a keyword and
requesting instead an endpoint to be passed. The patch gives priority to
the version in the endpoint and falls back to the keyword if the later is
not present.
Follow-up patches will improve this code making it interact a bit more
with the endpoint's catalog.
Closes-bug: #1395714
Change-Id: I4ada9e724ac4709429e502b5a006604ca0453f61
Allows passing --file and --progress to glance image-create with Image API v2.
if --file is present the image-create effectively calls image-upload with the
newly created image's id and the '--file' + '--progress' paramaters. The image
metadata will be printed after the upload call instead of after creation.
In a case argumented file does not exist the image will not be created and
error will be printed instead.
DocImpact
Closes-Bug: #1324067
Change-Id: I5d41fb2bbeb4e56213ae8696b84bf96b749414f8
This commit is removing the read-only properties from shell options to
prevent user from doing invalid requests using the client.
Change-Id: I17e9578e705bd3cf628fe39630ebecc4ea43e392
Closes-Bug: 1350802
The option is present in the v1 shell, but missing from the v2 shell. This
allows the user to filter based on any image property.
Example:
$ glance --os-image-api-version 2 image-list --property-filter os_distro=NixOS
DocImpact
Closes-Bug: #1383326
Change-Id: Ia65a08520e3eaf3ecd9b9018be9f6a8e2d3d4f0b
It's currently impossible to update properties which are defined in
image schema and which are not a base image property. Proposed fix skips
every non-base property when building a json patch, that is used to
update image properties through glance API.
Change-Id: I3b35cef379fcf437715e2966f9a0d25c1b4e4016
Closes-Bug: #1371559
Add tasks operations on client side to support task create,
list all and show.
DocImpact
Implement blueprint async-glance-workers
Change-Id: Ib4b8e347a8a47817e3b427c8ba024e8c32f65155
In the case where v2 requests are sent to a server which is not running
head of tree which includes the v2 metadef code some 404 cases need to
be handled to enable standard requests to complete.
This patch aslo improves fetching schemas -- they are now only
fetched as needed.
Change-Id: I8c871f11b909337bd7df19b77e606772dbc634b2
Closes-bug: #1367326
API calls and shell commands added in this patch:
- CRUD for metadefs namespaces;
- CRUD for metadefs objects;
- CRUD for metadefs properites;
- CRD for metadefs resource types and resource type associations.
Change-Id: I6d15f749038e8fd24fc651f0b314df5be7c673ef
Implements: blueprint metadata-schema-catalog-support
Co-Authored-By: Facundo Maldonado <facundo.n.maldonado@intel.com>
Co-Authored-By: Michal Dulko <michal.dulko@intel.com>
Co-Authored-By: Lakshmi N Sampath <lakshmi.sampath@hp.com>
Co-Authored-By: Pawel Koniszewski <pawel.koniszewski@intel.com>
This review implements blueprint python-request and replaces the old
http client implementation in favor of a new one based on
python-requests.
Major changes:
* raw_request and json_request removed since everything is now being
handled by the same method "_request"
* New methods that match HTTP's methods were added:
- get
- put
- post
- head
- patch
- delete
* Content-Type is now being "inferred" based on the data being sent:
- if it is file-like object it chunks the request
- if it is a python type not instance of basestring then it'll try
to serialize it to json
- Every other case will keep the incoming content-type and will send
the data as is.
* Glanceclient's HTTPSConnection implementation will be used if
no-compression flag is set to True.
Co-Author: Flavio Percoco<flaper87@gmail.com>
Change-Id: I09f70eee3e2777f52ce040296015d41649c2586a
The help message tells end user image-update interface accepts 'tags'
param and could be used to update tag of image [0], but actually it
could trigger an 400 exception [1] due to wrong PATCH calls, and the
correct way is to use image-tag-update interface [2] as designed.
[0] glance image-update <IMG_ID> --tags <TAG_VALUE>
[1] 400 Bad Request
Invalid JSON pointer for this resource: '/tags/0'
(HTTP 400)
[2] glance image-tag-update <IMG_ID> <TAG_VALUE>
Change-Id: Iaa8041779510192dc08f7b898b8a1beda29a6398
Signed-off-by: Zhi Yan Liu <zhiyanl@cn.ibm.com>
F841 detects local variable is assigned to but never used.
This commit fixes the violations and enables F841 in gate.
Change-Id: Ic4dcac2733dfe334009327ac17aa3952cafaa63a
According to my diagnosis [1], currently v2 API client consumed a lot
of CPU times by JSON schema validation on image model initialization
stage for image listing case. Because each image entry will triggers
one validation operation which spent most CPU clocks. (My test env has
1002 image entries now, so it's O(N) logic obviously).
This fix changed the original logic, it doesn't validate each image
entry but do it only on first image entry for each page. This approach
is a trade-off, it balanced the data validity and performance.
As comparison [3], under the fixed new logic, the execution time of
image listing is about four times as fast as old logic.
[1]
Clock type: CPU
Ordered by: totaltime, desc
name ncall ttot
..nt/v2/images.py:34 Controller.list 1003 12.08480
../warlock/core.py:30 image.__init__ 1002 11.91074
..warlock/model.py:28 image.__init__ 1002 11.90463
..arlock/model.py:130 image.validate 1002 11.73838
..nschema/validators.py:388 validate 1002 11.73682
[2]
name ncall ttot
..nt/v2/images.py:35 Controller.list 1003 1.100710
..nceclient/v2/images.py:45 paginate 256.. 1.099965
../warlock/core.py:30 image.__init__ 1002 0.944762
..warlock/model.py:28 image.__init__ 1002 0.939725
..arlock/model.py:130 image.validate 51 0.779653
..nschema/validators.py:388 validate 51 0.779431
[3]
$ time glance --os-image-api-version 2 image-list | grep 'test-' | wc -l
1000
real 0m16.606s
user 0m10.629s
sys 0m2.540s
$ time glance --os-image-api-version 2 image-list | grep 'test-' | wc -l
1000
real 0m4.151s
user 0m1.080s
sys 0m0.092s
Change-Id: Ia6598d3c06a5ff516277053c2b6fa5db744fe9cf
Signed-off-by: Zhi Yan Liu <zhiyanl@cn.ibm.com>
... and update tests to match.
The missing slash results in a non-absolute DELETE request
being sent to the API.
E.g.
DELETE v2/images/62fac489-23b4-4929-87af-2e7236e8542b HTTP/1.1
This is not strictly valid http/1.1 - rfc2616 specifies that the path must
be absolute.
This doesn't cause a problem for the API server, but this can cause
problems if the API server is fronted by something else (see #133161).
It also means that the curl command logged in debug mode has a
bad url.
E.g.
curl -i -X DELETE ... http://10.0.0.13:9292v2/images/...
Change-Id: Ib0c749dedbfcf07303fcddae4512db61b0f3fd78
Closes-bug: #1327101
Currently glanceclient's v2 commands don't support modification
operations on an image's location attribute - the argparse specification
for the location attribute of the image-update command causes the image
id argument to be included in list of locations and so the command
parsing fails (because it causes the image id to appear to be missing).
Furthermore even if the 'locations' argument were to be accepted by
argparse (e.g. by changing the argument specs and using --id to specify
the image id) the command would still fail because the arguments are
passed directly to the schema which expects the value of the 'locations'
argument to be a valid dictionary (there is nobody to convert the
argument string to a python dictionary that the schema expects).
This commit adds the following location related commands to
glanceclient:
--location-add: Add a new location to the list of image locations.
--location-delete: Remove an existing location from the list of
image locations.
--location-update: Update the metadata of existing location.
The glanceclient.v2.images.Controller class has been agumented with
three new methods to support the commands listed above:
- add_location
- delete_locations
- update_location
The server has not been modified, i.e. all location related API requests
are passed to the server via HTTP PATCH requests and handled by the
server's image update function.
The v2 'image' and 'shell' related tests have also been supplemented.
Note that in order to use these options the server must be first
configured to expose location related info to the clients (i.e.
'show_multiple_locations' must be set to 'True").
I also added a mailmap entry for myself.
DocImpact
Closes-bug: #1271452
Co-Author: David Koo (koofoss) <david.koo@huawei.com>
Change-Id: Id1f320af05d9344645836359758e4aa227aafc69
Currently only download method supports --progress flag in v2 API.
This patch let upload method in v2 API support this flag too.
Change-Id: I1d22379c320adb47a2178697e546413b9257f987
Closes-Bug: #1286265
Jenkins