yahoo-eng-team team mailing list archive

[OpenStack Infra <1621236@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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

** Affects: glance
     Importance: Undecided
         Status: New


** Tags: doc glance

-- 
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:
  New

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