Add a new import method called glance-download
that implements a glance to glance download in
a multi-region cloud with a federated Keystone.
This method will copy the image data and
selected metadata to the target glance, checking
that the downloaded size match the "size" image
attribute in the source glance.
Implements: blueprint glance-download-import
Co-Authored-By: Victor Coutellier <victor.coutellier@gmail.com>
Change-Id: Ic51c5fd87caf04d38aeaf758ad2d0e2f28098e4d
In Xena we have mangaed to move all policy checks to API layer,
now removing the dead code from policy and authorization layer
NOTE: Some of the code is still being used from policy layer,
hence keeping it there only at this moment.
Change-Id: Ibee749cde20687d8c243cf84ae80b4de67d8ef3d
This was already fixed in 4889dc1814 but
we did not enforce this rule and reintroduced "bad" string
interpolations. This patch adds a hacking rule to prevent us from doing
this again in the future.
Change-Id: I96d9a157d3887286542859d67138ffdae5a589f1
This is a rather beefy change due to the number of usages of this
import. The changes are trivial though.
Change-Id: I7badeeaca438b0291f4ed86670e7f217e6372c61
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This patch enforces policy checks required for fetching task
information for image in API layer.
Partially-Implements: blueprint policy-refactor
Depends-On: https://review.opendev.org/c/openstack/nova/+/688802
Change-Id: I8f59b8405d9c55b5f69294d3f9bd7bcbc064203f
This patch enforces policy checks required for importing/copying image
data to store in API layer.
Partially-Implements: blueprint policy-refactor
Change-Id: I18a5187d80bf76c0dc6f22dd8c96a8ffa0f46dc1
These change enforce policies required for deleting image from store
in API layer.
Partially-Implements: blueprint policy-refactor
Closes-Bug: #1939977
Change-Id: If390f04aef00fa4e6dc792658ae5fee9917c7d1f
Note that this adds a clause to the delete exception handler which
returns 404 if the user can't delete the image via policy, but leaves
the existing internal forbidden->403 handler because of how image
property protections work.
Partially-Implements: blueprint policy-refactor
Change-Id: I5f2a406e31b706906b71ea5ecb4f1a53674c97fa
This includes a change to catch Forbidden and convert to NotFound.
The previous Forbidden handler was not only correct (it shoud hide
the permissions error with "not found") but it was actually dead code,
since the DB was performing its own checks and would never raise
Forbidden.
This also includes a change of the default policy for get_images
to include the other states, like get_image does. I think this was
just an oversight in the original RBAC patches, which didn't matter
because they weren't really being honored strictly.
Partially implements: blueprint policy-refactor
Change-Id: I70100cd7f01da803e9740cea1f7ce7ae18ad6919
This implements the proposal at the PTG that makes the image update
API our first one to do all policy checks at the API layer instead
of the lower ones.
There are still some things that have to be resolved, like the image
repo will still check get_image even though we don't want it to.
However, this adds a new v2/policy module to encapsulate these checks
and adds them into the various places of the update call. It also
makes our test policy for modify_image match that of our actual
default, which is a major step in making sure our tests actually run
with the policy we expect at runtime.
NOTE: db.ImageRepo.save() was raising NotFound in cases where
Forbidden was raised by _check_mutate_authorization(). This means
that we could not tell the difference at the higher layers between
an actual NotFound and the 404 generated by an auth failure.
The ImageAPIPolicy module will raise Forbidden for cases where an
operation is forbidden, but the image would be otherwise visible to
the user, and NotFound otherwise to obscure the existence of images
that the user can not otherwise see.
Partially-Implements: blueprint policy-refactor
Change-Id: I43dbc88a9f3fd4c6b2a10c2534ccee9283663282
This makes us enforce a quota on the total number of upload-related
image operations owned by a user.
Partially-implements: blueprint glance-unified-quotas
Change-Id: I2a28750aaf968e6a6324eb194d4280a640bfa5aa
This makes us enforce a quota on the total number of (non-deleted)
images owned by a user.
Partially-implements: blueprint glance-unified-quotas
Change-Id: I8af124d9307263cd8289d0701fb9a745d13b1d56
This adds enforcement of the image_size_total keystone limit for
image upload and import. We simply check the quota before either of
these operations and refuse to proceed further if the user is over
their quota.
Note that this disables checking of the global size quota if keystone
quotas are enabled.
Note this includes another fix to couple unit tests that do not
properly pass context to the get_flow() method.
Partially-implements: blueprint glance-unified-quotas
Change-Id: Idf5f004b72436df1f9c77bb32d60b9be5ae77a68
This implements distributed image import support, which addresses
the problem when one API worker has staged the image and another
receives the import request.
The general approach is that when a worker stages the image, it
records its self-reference URL in the image's extra_properties. When
the import request comes in, any other host will proxy that HTTP
request direct to the original host instead of trying to do the import
itself.
Implements: blueprint distributed-image-import
Change-Id: I12daccb43c535b579c22f9d0742039b2ab42e929
Added new API /v2/images/{id}/tasks to show tasks associated with
image. This API will return list of tasks associated for valid image
else returns 404 not found if image is not present. This API also
initiates task scrubbing before returning tasks to user.
Implements: blueprint messages-api
Change-Id: Ib3cacb4dd4d75de32e539f8a3b48bdaa762e6d8e
Made provision to pass image_id, request_id and user_id information
while creating new task.
Partially-Implements: blueprint messages-api
Change-Id: I299a222eeef81431143db3ba7fc08365c924326b
req.context has been used in various places in import_image and create
method, this patch extract that in a variable for furthrer use.
Change-Id: I9d09769f971477b4d9a9a3a7d458deb19d1f3c8c
Related: blueprint messages-api
Now that glance is using properties in the os_glance namespace for
internal purposes, we should exclude the counting of these from the
enforced image property quota.
Change-Id: I5fbe5eb12fd34e054137732a02c4cc5b687e7c77
Related-Bug: #1912001
This adds a general mechanism for reserving property names that start
with os_glance. This has been done informally already, but no
enforcement was performed, except for specific keys on update. As a
result, banning these keys from create, for example, was missed and
users are able to set these keys during an POST /images operation.
Depends-On: https://review.opendev.org/c/openstack/nova/+/771234
Change-Id: I31b4dae018d52ead773db25472013d783066ee17
Closes-Bug: #1912001
When we bust a lock, we now own the image for that time period
and may exclude the other task (if still running) from updating
the import status information. If not still running, we should
take responsibility of that cleanup since we know what task we
stole the lock from. We should, however, only do that if we
succeed in grabbing the lock to avoid racing with another thread
which might be trying to do the same thing.
Change-Id: Iff3dfbfcbfb956a06d77a144e5456bdb556c5a2c
This attempts to provide a time-based import lock that is dependent
on the task actually making progress. While the task is copying
data, the task message is updated, which in turn touches the task
updated_at time. The API will break any lock after 30 minutes of
no activity on a stalled or dead task. The import taskflow will
check to see if it has lost the lock at any point, and/or if its
task status has changed and abort if so.
The logic in more detail:
1. API locks the image by task-id before we start the task thread, but
before we return
2. Import thread will check the task-id lock on the image every time it
tries to modify the image, and if it has changed, will abort
3. The data pipeline will heartbeat the task every minute by updating
the task.message (bonus: we get some status)
4. If the data pipeline heartbeat ever finds the task state to be changed
from the expected 'processing' it will abort
5. On task revert or completion, we drop the task-id lock from the image
6. If something ever gets stuck or dies, the heartbeating will stop
7. If the API gets a request for an import where the lock is held, it
will grab the task by id (in the lock) and check the state and age.
If the age is sufficiently old (no heartbeating) and the state is
either 'processing' or terminal, it will mark the task as failed,
steal the lock, and proceed.
Lots of logging throughout any time we encounter unexpected situations.
Closes-Bug: #1884596
Change-Id: Icb3c1d27e9a514d96fca7c1d824fd2183f69d8b3
Stores is image property which API uses to indicate which
stores (store IDs) contains the image. This also can be
set by user making it very confusing and potentially
catastrophic breaking for consumers.
This patch prevents that to happen.
Depends-on: https://review.opendev.org/#/c/744024/
Change-Id: I4eca092bd0a7cce1d6bbbd30685f4643cb4e7d1c
Closes-Bug: #1889676
This teaches glance-api how to do async threading things when it is
running in pure-WSGI mode. In order to do that, a refactoring of things
that currently depend on eventlet is required.
It adds a [wsgi]/task_pool_threads configuration knob, which is used
in the case of pure-WSGI and native threads to constrain the number
of threads in that pool (and thus the task parallelism). This will
allow tuning by the operator, but also lets us default that to just
a single thread in the backport of these fixes so that we can avoid
introducing a new larger footprint in the backport unexpectedly.
Partial-Bug: #1888713
Depends-On: https://review.opendev.org/#/c/742047/
Change-Id: Ie15028b75fb8518ec2b0c0c0386d21782166f759
This adds a copy_image policy knob which can be used to grant users
the ability to copy images other than their own using the new
functionality just added to the api_image_import task. By default,
only admins are allowed to do this.
A functional test modification is included to show that users can
be granted permission to do this based on something like the
"public visibility" attribute of an image.
Change-Id: Idebf66e2944bcddb7a5c76b81e47c654b401c2a8
This makes the api_image_import task capable of running as an admin on
behalf of a user if so authorized by the API. It includes a new object
called ImportActionWrapper which provides a bundle of utility methods
which can be run either against the user-authorized or admin-authorized
ImageRepo passed in from the API. It encapsulates all the actions
we are able and willing to run as an admin for the user.
This is currently not drivable by the API because the policy check is
still statically defined as "admin or owner" but this change is
offered without any needed modification to the functional tests to
prove that it does not regress existing functionality. The following
patch will introduce a more robust knob for allowing users to do this,
and it brings the functional test changes with it.
Change-Id: Iac75956e314ec6f41db18430486bd8be9754e780
Glance has a facility lazy loading for legacy images which will be called
on get/list api calls to add store information in image's location metadata
based on location URL of image. Even if admin decides to change the store
names in glance-api.conf same will also be updated in location metadata
for all images related to that particular store. Current implementation of
legacy image performs this operation on each get/list call as location metadata
is not getting updated in database or it doesn't handle to perform store name
check in glance-api.conf.
Improvements done:
1. Save updated location metadata information in database permenantly
2. Add logic to perform lazy loading only if store information is not present
in location metadata or store present in location metadata is not defined in
glance's enbaled_backends configuration option.
Change-Id: I789fa7adfb459e7861c90a51f418a635c0c22244
Closes-Bug: #1886374
Right now we only check to see if the user can see the image before
we kick off an import operation. However, that will never work unless
the user is the *owner* of the image (or an admin) which means we
return a 202 to the API caller and then the task fails immediately.
This change makes us check that authorization up front and return an
appropriate error to the user so they know it failed, and avoid
starting a task destined for failure.
Note that there was already a check for a Forbidden result when calling
the import API. However, that used a context.owner=None which could never
happen in reality. A more suitable check would have been to use a context
with a different real owner, but it turns out that the task creation
would have succeeded in that case as well. This test is changed to use
an alternate owner and ensure that we get the forbidden result from the
new check immediately.
Change-Id: I385f222c5e3b46978b40bdefdc28fcb20d9c67d3
Closes-Bug: #1884587
If user passes 'all_stores_must_succeed' as 'false' in copy-image, multiple
image imports request body then it does not work as expected. Expected is
to skip the failure store and continue copying/importing image to other
stores but instead it stops execution of task and revert it and deletes
the image data copied/imported to previois stores.
Raised 400 BadRequest if 'all_stores_must_succeed' and 'all_stores' are
other thatn than boolean values.
NOTE: Documentation clearly suggest that we expect boolean values for
'all_stores_must_succeed' and 'all_stores'
Closes-Bug: #1871588
Change-Id: I5118489284fea007f8f29663581221b07a575cf3
We were capped at a very old version of hacking. Hacking itself caps the
various linters it uses to remain consistent, so our pep8 job was not
checking quite a bit that current versions have added.
This raises that limit to the latest to get up to the level of other
projects and addresses the errors the updated linters uncovered.
Change-Id: I89a9d73fbd59606a649e26077acebc5c42873d67
Co-authored-by: Sean McGinnis <sean.mcginnis@gmail.com>
This change introduces new 'v2/stores/<store_id>/<image_id>'
endpoint that accepts 'DELETE' method request. Once successful
the request will delete the image <image_id>'s location that
matches the store <store_id>. If the store is not read-only
or return image in use exception the image data will be
deleted. In the case of read-only store, the location will
be removed and if the image in use is raised, the call will
fail.
bp: delete-from-store
Co-authored-by: Brian Rosmaita <rosmaita.fossdev@gmail.com>
Change-Id: I1cb45026489a96a283b82e8e7efc9975c181fceb
Added new import method 'copy-image' which will copy existing image into
specified list of stores. Introduced additional task which will serve
as internal plugin which will allow copying existing image into staging
area and then this data will be uploaded to specified stores via regula
import flow.
NOTE: This new import method 'copy-image' is only supported if multiple
stores are enabled in deployment.
APIImpact
Implements: blueprint copy-existing-image
Change-Id: I13eaab7ab013f44ce18465bdbdbe8052942570ff
The import image api now supports a list of stores to import data into.
This list can be specified through a new "stores" field that has been
added to the request body.
During import stage, Glance iterates overs this list and send the data
to each store one by one.
If an invalid backend is requested by the user, an exception is raised.
If an errors occurs during verify, already pushed data is removed and
image state is unchanged.
Change-Id: Id3ac19488c0a693d7042be4a3c83f3b9f12313d0
Implements: blueprint import-multi-stores
If multiple stores configured in glance and Image is deleted while import
operation is in progress then image data stays in staging area
(filesystem backend) and there is no other way than clearing it
manually.
Modified delete method to delete the data from staging area if image is
deleted while import operation is in progress.
Change-Id: Ib58accd6514e589dccde57fe063815b1ab1ce496
Closes-Bug: #1855417
In Rocky multiple backend support is added as experimental feature. In
order to take advantage of this feature it is decided to deprecate
work_dir and node_staging_uri configuration options
and reserve two filesystem stores 'os_glance_tasks_store' and
'os_glance_staging_store', which can be used to get rid of initializing
store via internal functions.
These internal stores are considered "reserved stores" by Glance.
For the time being, these are hard-coded as filesystem stores. The
store prefix 'os_glance_' is reserved for internal Glance use and
the glance-api service will refuse to start if a store with this
prefix is included in the enabled_backends config option in
glance-api.conf.
NOTE: Because there are no sensible default values for the location
of the datadir for each of these stores, the operator must define
'os_glance_tasks_store' and 'os_glance_staging_store' in
glance-api.conf configuration file as shown below.
[os_glance_tasks_store]
filesystem_store_datadir = /var/lib/glance/tasks_work_dir/
[os_glance_staging_store]
filesystem_store_datadir = /var/lib/glance/staging/
Each filesystem store must have a unique datadir.
Depends-On: https://review.openstack.org/#/c/639765/
Implements: blueprint rethinking-filesystem-access
Change-Id: I86ec513c5fc653dbb97b79d953d8430f014e684f
We add two extra properties for images:
- cinder_encryption_key_id, which stores the encryption key id;
- cinder_encryption_key_deletion_policy, which states whether the secret
key should be deleted on image deletion.
This feature uses the Castellan key manager, and will therefore work
with all its supported backends.
Implements: blueprint barbican-secret-deletion-support
DocImpact
Change-Id: Iacd0b3785ad4cdd06961e6d11967775806e009ff
In case of Multiple store while adding location to image if backend store is
not provided it returns 400 BadRequest saying 'Invalid location'.
Made changes to loaction API to findout the store from location URI
and add it as a backend store to the location metadata.
DocImpact
Closes-Bug: #1802587
Co-Authored-By: Victor Coutellier <victor.coutellier@gmail.com>
Change-Id: If6d0348346d2086a2500b0012a0e81e80cea7395
As a part of vocabulary correction, changed the location
metadata key name from 'backend' to 'store'. Modified
corresponding tests as well.
bp:multi-store-vocabulary-correction
Change-Id: Iae3503cba6be362b372e1fc3e75c2ddb1e99b763
When image import fails during image is uploading from staging area,
image remains in uploading state and data remains in staging area. In
this scenario if 'file' store is not enabled then while deleting the
image glance-api returns 500 status code with error 'file' scheme is
Unknwon.
Used os module to unlink the file present in staging area explicitly to
delete the data from staging area.
Change-Id: I57dcd6b18b0039e824e8adbe77de59079360a34f
Closes-Bug: #1836140
Glance tests are currently too verbose for subunit and make
them randomly fail under python 3.
Using raw strings should avoid the DeprecationWarnings around
'invalid escape sequence' being used with the re module.
Change-Id: I14c381ac4b17ca4c5755ed78c55dc44362ab37ef
Abhishek Kekane