yahoo-eng-team team mailing list archive

[OpenStack Infra <1621236@xxxxxxxxxxxxxxxxxx>]

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 <alexander.bashmakov@xxxxxxxxx>
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 <mfedosin@xxxxxxxxxxxx>
  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 <mfedosin@xxxxxxxxxxxx>
      Co-Authored-By: Nikhil Komawar <nik.komawar@xxxxxxxxx>
      
      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