yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #59534
[Bug 1648111] [NEW] Restrict location updates to active, queued images
Public bug reported:
https://review.openstack.org/366995
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 4ac8adbccc2b7bbef3d53f9141079c48f9c768f4
Author: Nikhil Komawar <nik.komawar@xxxxxxxxx>
Date: Wed Sep 7 17:29:41 2016 -0400
Restrict location updates to active, queued images
Currently image location updates (removing, replacing) are permitted for
images even if their state is not ``active``.
This need is to:
* Prevent the replacement of image locations of images that are not
``active`` or ``queued`` by returning a Conflict Error
(409 response code).
* Prevent removal of image locations of images that are not ``active``
by returning a Conflict Error (409 response code).
Changing of image locations when the image state is not ``active`` can
result in bad experiences for the users.
* If one tries to change or remove the location for an image while it
is in ``saving`` state, Glance would be trying to write data to a
previously saved location while the user updates the custom
location. This results in a race condition.
* For images that are in ``queued`` state and no image data has been
uploaded yet, there is no need for an image location to be
removed and permitting users to remove the image
location can result in a bad experience. However users can be
allowed to replace the image location to maintain backward
compatibility and also because replacing could mean replacing an
empty location by a non-empty image location.
* For images in ``deactivated`` state, it is essential that image
locations are not updated as it does not abide with the purpose of
the image state being set to ``deactivated`` and may cause security
concerns.
This commit introduces the following change in behavior:
* If an image is in ``active`` state, removing/replacing the custom
locations on that image will be allowed so there is no change in
behavior for this case.
* If an image is in ``saving`` or ``deactivated``, the status of
that image will be checked while trying to replace/remove the custom
location and a HTTP 409 Conflict status will be returned in response
to the user.
* If an image is in ``queued`` state, removing the custom
image location will not be permitted as an image in queued status
should not have any location associated with it. Replacing of location
may be permitted here though.
* If an image is in ``deleted`` or ``pending_delete`` state, a HTTP
409 Conflict status will be returned, if that image is visible to
the user (in case of admins). Otherwise, the location cannot be
removed/replaced anyway. 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 returned.
TODO:
Atomicity is required such that glance permits removal/replacement of
image locations on certain permissible image transition states handling
the race conditions like:
* In case where the status of the image is ``saving`` and it
has just moved to ```active`` status, ideally removing/replacing
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
removing/replacing custom location should be allowed. Again, due
to lack of atomicity in setting image status glance will ignore
the request 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 remove/replace
the 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 replace the location for
that image.
* In case where the status of the image is ``active`` and location
is attempted to be set on it, and at that point if the image goes
into ``deleted``, ``pending_delete`` or ``killed`` status, then the
user must get a HTTP 409 Conflict status. However due to lack of
atomicity in setting the image status, the location may get updated.
NOTE:
This commit ensures that removal of image locations
is not allowed for an image in any state except ``active`` and
replacement of an image location is not allowed except for ``active``
and ``queued`` images.
Further work is required on the atomicity of glance to accommodate
location updates in cases where the images would be undergoing state
changes.
Impacts:
APIImpact
DocImpact
Credits:
This commit message contains text and information from the commit
message for: https://review.openstack.org/#/c/324012/
co authored by Nikhil Komawar <nik.komawar@xxxxxxxxx>.
Co-Authored-By: Nikhil Komawar <nik.komawar@xxxxxxxxx>
Co-Authored-By: Dharini Chandrasekar <dharini.chandrasekar@xxxxxxxxx>
Lite-Spec: https://review.openstack.org/#/c/368192/
Closes-Bug: 1622016
Change-Id: Ic24cf8234599a32add1cb9f294f902e497d885e0
** 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/1648111
Title:
Restrict location updates to active, queued images
Status in Glance:
New
Bug description:
https://review.openstack.org/366995
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 4ac8adbccc2b7bbef3d53f9141079c48f9c768f4
Author: Nikhil Komawar <nik.komawar@xxxxxxxxx>
Date: Wed Sep 7 17:29:41 2016 -0400
Restrict location updates to active, queued images
Currently image location updates (removing, replacing) are permitted for
images even if their state is not ``active``.
This need is to:
* Prevent the replacement of image locations of images that are not
``active`` or ``queued`` by returning a Conflict Error
(409 response code).
* Prevent removal of image locations of images that are not ``active``
by returning a Conflict Error (409 response code).
Changing of image locations when the image state is not ``active`` can
result in bad experiences for the users.
* If one tries to change or remove the location for an image while it
is in ``saving`` state, Glance would be trying to write data to a
previously saved location while the user updates the custom
location. This results in a race condition.
* For images that are in ``queued`` state and no image data has been
uploaded yet, there is no need for an image location to be
removed and permitting users to remove the image
location can result in a bad experience. However users can be
allowed to replace the image location to maintain backward
compatibility and also because replacing could mean replacing an
empty location by a non-empty image location.
* For images in ``deactivated`` state, it is essential that image
locations are not updated as it does not abide with the purpose of
the image state being set to ``deactivated`` and may cause security
concerns.
This commit introduces the following change in behavior:
* If an image is in ``active`` state, removing/replacing the custom
locations on that image will be allowed so there is no change in
behavior for this case.
* If an image is in ``saving`` or ``deactivated``, the status of
that image will be checked while trying to replace/remove the custom
location and a HTTP 409 Conflict status will be returned in response
to the user.
* If an image is in ``queued`` state, removing the custom
image location will not be permitted as an image in queued status
should not have any location associated with it. Replacing of location
may be permitted here though.
* If an image is in ``deleted`` or ``pending_delete`` state, a HTTP
409 Conflict status will be returned, if that image is visible to
the user (in case of admins). Otherwise, the location cannot be
removed/replaced anyway. 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 returned.
TODO:
Atomicity is required such that glance permits removal/replacement of
image locations on certain permissible image transition states handling
the race conditions like:
* In case where the status of the image is ``saving`` and it
has just moved to ```active`` status, ideally removing/replacing
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
removing/replacing custom location should be allowed. Again, due
to lack of atomicity in setting image status glance will ignore
the request 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 remove/replace
the 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 replace the location for
that image.
* In case where the status of the image is ``active`` and location
is attempted to be set on it, and at that point if the image goes
into ``deleted``, ``pending_delete`` or ``killed`` status, then the
user must get a HTTP 409 Conflict status. However due to lack of
atomicity in setting the image status, the location may get updated.
NOTE:
This commit ensures that removal of image locations
is not allowed for an image in any state except ``active`` and
replacement of an image location is not allowed except for ``active``
and ``queued`` images.
Further work is required on the atomicity of glance to accommodate
location updates in cases where the images would be undergoing state
changes.
Impacts:
APIImpact
DocImpact
Credits:
This commit message contains text and information from the commit
message for: https://review.openstack.org/#/c/324012/
co authored by Nikhil Komawar <nik.komawar@xxxxxxxxx>.
Co-Authored-By: Nikhil Komawar <nik.komawar@xxxxxxxxx>
Co-Authored-By: Dharini Chandrasekar <dharini.chandrasekar@xxxxxxxxx>
Lite-Spec: https://review.openstack.org/#/c/368192/
Closes-Bug: 1622016
Change-Id: Ic24cf8234599a32add1cb9f294f902e497d885e0
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1648111/+subscriptions
Follow ups
