Reviewed: https://review.openstack.org/370413 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=e170225f3f4558bd13d302ac4379dd318cb12c93 Submitter: Jenkins Branch: master
commit e170225f3f4558bd13d302ac4379dd318cb12c93 Author: Alexander Bashmakov <[email protected]> Date: Wed Sep 14 13:19:23 2016 -0700 Update api-ref with 409 response to image update. With the change [1] that went into Newton to disallow image location updates except for 'queued' and 'active' states, this patch adds appropriate api-ref documentation. Related change [2] bumps the minor API version to 2.4. [1] https://review.openstack.org/324012 [2] https://review.openstack.org/350809 Change-Id: I593ad2d3c7402c4fb87a475c8d44060baed5ff69 Closes-Bug: 1621236 ** Changed in: glance Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1621236 Title: Attempt to not set location on non active or queued image Status in Glance: Fix Released Bug description: https://review.openstack.org/324012 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/glance" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 7c7dd626896d732d75c6b802a33b9462aee885fd Author: Mike Fedosin <[email protected]> Date: Wed Jun 1 19:38:48 2016 +0300 Attempt to not set location on non active or queued image Currently, an authorized user can set custom location string to an image that is in any non-deleted status. If a custom location is set to an image in ``saving`` status, it may result in a race condition between the data stream that is trying to save the image data to the backend and the custom location user is attempting to set on the image record. This will result in a bad experience for the user who is streaming the image data to Glance as it is a better experiece to set the location after the image data has been saved and image is in ``active`` status, in this case. If a custom location is set to an image in ``deactivated`` status, the purpose of setting the image to ``deactivated`` is void. This will result in a worse experience for the security team that is trying to evaluate the validity of the image data of the deactivated image. Avoiding setting custom location in this case will ensure data consistency until image is pulled out of the deactivation process. This commit introduces the following change in behavior: * If an image is in ``saving`` or ``deactivated`` status, the staus of that image will be checked while trying to set the custom location and a HTTP 409 Conflict status will be retured in response to the user. * If an image is in ``active`` or ``queued`` status, setting custom locations on that image will be allowed so there is no change in behavior for this case. * If an image is in ``deleted`` or ``pending_delete`` status, a HTTP 409 Conflict status will be retured, if that image is visible to the user (in case of admins). Otherwise, the location cannot be set anyway. Setting a location to a ``deleted`` image is fruitless as the image cannot be used. Please note ``pending_delete`` is another form of the ``deleted`` status and behavior in either case should be expected to be same. * If an image is in ``killed`` status, a HTTP 409 Conflict status will be retured. Nevertheless, it is again fruitless to attempt to set a location on such images as they are unusable. * This operation still involves the following race conditions: * In case where the status of the image is ``saving`` and it has just moved to ```active`` status, ideally setting custom location should be allowed however, due to lack of atomicity in setting image status glance will ignore setting the location and a 409 will be returned. * In case where the status of the image is ``deactivated`` and it has just been moved to ``active`` status, ideally setting custom location should be allowed however, due to lack of atomicity in setting image status glance will ignore setting the location and a 409 will be returned. * In case where the status of the image is ``active`` and it has just been moved to ``deactivated`` status, due to lack of atomicity in setting image status, glance may set another location on that image. * In case where the status of the image is ``queued`` and it has just been moved to ``saving`` status, due to lack of atomicity in setting image status, glance may set another location on that image. * In case where the status of the image is ``queued`` or ``active`` and location is attempted to be set on it, if the image first goes into ``deleted``, ``pending_delete`` or ``killed`` status then the user will get a HTTP 409 Conflict status back. This occurs again due to lack of atomicity in setting image status. Please note: * We will plan to add further granularity in setting locations to the images atomically in subsequent commits. * Fow now, though, this commit does resolve the issue of setting locations on an image incorrectly (in unexpected circumstances) to a significant degree. So, this is good progress in ensuring rightful use of the image locations feature. APIImpact DocImpact Co-Authored-By: Mike Fedosin <[email protected]> Co-Authored-By: Nikhil Komawar <[email protected]> Change-Id: Ie463e2f30db94cde7716c83a94ec2fb0c0658c91 Lite-Spec: https://review.openstack.org/#/c/324780/ Partial-Bug: 1587985 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1621236/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
