openstack/glance-specs
Code Issues Proposed changes

Update specs repo for Ocata

Browse Source 
Created the 'implemented' directory and moved appropriate specs out of
'approved' and into it.

Change-Id: Iba7f85a28115639c520c239d063a54e92ef01a37
This commit is contained in:
Brian Rosmaita 2017-02-03 23:25:48 -05:00
parent 401490599f
commit cb0668d8ea
7 changed files with 146 additions and 159 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

162
specs/ocata/approved/glance/lite-specs.rst
View File

@ -2,159 +2,8 @@
Glance Spec Lite
================
Please keep this template section in place and add your own copy of it between the markers.
Please fill only one Spec Lite per commit.
<Title of your Spec Lite>
-------------------------
:problem: <What is the driver to make the change.>
:solution: <High level description what needs to get done. For example: "We need to
add client function X.Y.Z to interact with new server functionality Z".>
:impacts: <All possible \*Impact flags (same as in commit messages) or 'None'.>
Optionals (please remove this line and fill or remove the rest until End of Template):
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
:how: <More technical details than the high level overview of `solution` if needed.>
:alternatives: <Any alternative approaches that might be worth of bringing to discussion.>
:timeline: <Estimation of the time needed to complete the work.>
:link: <Link to the change in gerrit that already would provide the `solution`.
After commiting the Spec Lite depend the change to the Spec Lite commit.>
:reviewers: <If reviewers has been agreed for the functionality, list them here.>
:assignee: <If known, list who is going to work on the feature implementation here>
End of Template
+++++++++++++++
Return 409 if removing/replacing the location of an image that's not ``active``
-------------------------------------------------------------------------------
:problem: When ``show_multiple_locations`` is set to ``True``, users currently
can remove or replace locations of an image irrespective of the image
status. This can result in bad experiences for the users:- 1) 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. 2) 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. 3) 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.
:solution: 1) Return Conflict Error (409 response code) if an attempt to remove
the image location is made when the status of the image
is anything but ``active``. 2) Return Conflict Error (409 response
code) if an attempt to replace the image location is made when the
status of the image is anything but ``active`` or ``queued``.
:impacts: A Conflict Error will be thrown preventing users from removing an
image location when the image status is not ``active`` and replacing
an image location when the image status is not ``active`` or ``queued``.
:timeline: Expected to be merged within the ocata-1 time frame.
:link: https://review.openstack.org/#/c/366995/
:assignee: Nikhil Komawar, Dharini Chandrasekar
Return 409 if removing/replacing the location of an image that's not ``active``
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Expand hypervisor_type metadata with Virtuozzo hypervisor
---------------------------------------------------------
:problem: Currently it is not possible to require Virtuozzo hypervisor
by specifying hypervisor_type metadata, though Nova has had
Virtuozzo support since the Kilo release.
:solution: We need to expand etc/metadefs/compute-hypervisor.json
hypervisor_type property with the appropriate identifier, 'vz',
as defined in
http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/hv_type.py.
:impacts: This will have documentation impact. Release note should
be added to notify interested parties about this addition.
:timeline: Expected to be merged within the O-2 time frame.
:link: https://review.openstack.org/#/c/341623/
:assignee: Maxim Netratov
End of Expand hypervisor_type metadata with Virtuozzo hypervisor
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Add `ploop` to the list of supported disk formats
-------------------------------------------------
:problem: Currently 'ploop' format is not among supported by default disk
formats, even though it's been supported by Nova since the Kilo release.
:solution: `disk_formats` configuration option needs to be updated to add
'ploop' as one of the supported format.
:impacts: This will have documentation impact. Release note should
be added to notify interested parties about this addition.
:timeline: Expected to be merged within the O-2 time frame.
:link: https://review.openstack.org/#/c/341633/
:assignee: Maxim Netratov
End of Add `ploop` to list of supported disk formats
++++++++++++++++++++++++++++++++++++++++++++++++++++
Use ``Range`` HTTP header instead of ``Content-Range`` for parsing requests
---------------------------------------------------------------------------
:problem: When a HTTP request for a partial image download is sent, currently
the ``Content-Range`` header is parsed to get the byte range from the
request. Per RFC 7233 specification, the desired byte range
should be specified in HTTP requests using the ``Range`` header
rather than the ``Content-Range`` header. The latter is reserved for
responses to such requests. Current implementation requires users to
send requests that are not compatible with this specification.
For example, a user has to give "bytes 12-30/32" instead of
"bytes=12-32".
:solution: Parse the ``Range`` header from HTTP requests and send a
``Content-Range`` entity header with the server response.
Deprecate and retain the current support for ``Content-Range``
header requests for backward compatibility reasons.
:impacts: Users will be able to send partial download requests using the
``Range`` header in the requests with the appropriate value formats.
For developers, the ``Range`` webob parser does not have a length
attribute. We will have to pass the image size explicitly and perform
checks to identify an unsatisfiable byte range request from the
parsed ``Range`` header. This change will also require an API
version bump.
:timeline: Expected to be merged within the Ocata time frame.
:link: https://review.openstack.org/#/c/367528/
:assignee: Dharini Chandrasekar
Use ``Range`` HTTP header instead of ``Content-Range`` for parsing requests
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Rplace mox with mock for unit test
----------------------------------
Replace mox with mock for unit test
-----------------------------------
:problem: ``Mox`` does not support python 3. We have a shim module 'mox3' that was
built a couple of years ago, is unmaintained, and as it gets tested
@ -170,8 +19,5 @@ Rplace mox with mock for unit test
:assignee: Howard Lee
Rplace mox with mock for unit test
++++++++++++++++++++++++++++++++++
Add your Spec Lite before this line
===================================
`End of` Replace mox with mock for unit test
++++++++++++++++++++++++++++++++++++++++++++

0
specs/ocata/approved/glance/alembic-migrations.rst → specs/ocata/implemented/glance/alembic-migrations.rst
View File

0
specs/newton/approved/glance/community_visibility.rst → specs/ocata/implemented/glance/community_visibility.rst
View File

0
specs/ocata/approved/glance/database-strategy-for-rolling-upgrades.rst → specs/ocata/implemented/glance/database-strategy-for-rolling-upgrades.rst
View File

122
specs/ocata/implemented/glance/lite-specs.rst Normal file
View File

@ -0,0 +1,122 @@
================
Glance Spec Lite
================
Return 409 if removing/replacing the location of an image that's not ``active``
-------------------------------------------------------------------------------
:problem: When ``show_multiple_locations`` is set to ``True``, users currently
can remove or replace locations of an image irrespective of the image
status. This can result in bad experiences for the users:- 1) 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. 2) 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. 3) 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.
:solution: 1) Return Conflict Error (409 response code) if an attempt to remove
the image location is made when the status of the image
is anything but ``active``. 2) Return Conflict Error (409 response
code) if an attempt to replace the image location is made when the
status of the image is anything but ``active`` or ``queued``.
:impacts: A Conflict Error will be thrown preventing users from removing an
image location when the image status is not ``active`` and replacing
an image location when the image status is not ``active`` or ``queued``.
:timeline: Expected to be merged within the ocata-1 time frame.
:link: https://review.openstack.org/#/c/366995/
:assignee: Nikhil Komawar, Dharini Chandrasekar
`End of` Return 409 if removing/replacing the location of an image that's not ``active``
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Expand ``hypervisor_type`` metadata with Virtuozzo hypervisor
-------------------------------------------------------------
:problem: Currently it is not possible to require Virtuozzo hypervisor
by specifying hypervisor_type metadata, though Nova has had
Virtuozzo support since the Kilo release.
:solution: We need to expand etc/metadefs/compute-hypervisor.json
hypervisor_type property with the appropriate identifier, 'vz',
as defined in
http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/hv_type.py.
:impacts: This will have documentation impact. Release note should
be added to notify interested parties about this addition.
:timeline: Expected to be merged within the O-2 time frame.
:link: https://review.openstack.org/#/c/341623/
:assignee: Maxim Netratov
`End of` Expand ``hypervisor_type`` metadata with Virtuozzo hypervisor
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Add ``ploop`` to the list of supported disk formats
---------------------------------------------------
:problem: Currently 'ploop' format is not among supported by default disk
formats, even though it's been supported by Nova since the Kilo release.
:solution: `disk_formats` configuration option needs to be updated to add
'ploop' as one of the supported format.
:impacts: This will have documentation impact. Release note should
be added to notify interested parties about this addition.
:timeline: Expected to be merged within the O-2 time frame.
:link: https://review.openstack.org/#/c/341633/
:assignee: Maxim Netratov
`End of` Add ``ploop`` to list of supported disk formats
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Use ``Range`` HTTP header instead of ``Content-Range`` for parsing requests
---------------------------------------------------------------------------
:problem: When a HTTP request for a partial image download is sent, currently
the ``Content-Range`` header is parsed to get the byte range from the
request. Per RFC 7233 specification, the desired byte range
should be specified in HTTP requests using the ``Range`` header
rather than the ``Content-Range`` header. The latter is reserved for
responses to such requests. Current implementation requires users to
send requests that are not compatible with this specification.
For example, a user has to give "bytes 12-30/32" instead of
"bytes=12-32".
:solution: Parse the ``Range`` header from HTTP requests and send a
``Content-Range`` entity header with the server response.
Deprecate and retain the current support for ``Content-Range``
header requests for backward compatibility reasons.
:impacts: Users will be able to send partial download requests using the
``Range`` header in the requests with the appropriate value formats.
For developers, the ``Range`` webob parser does not have a length
attribute. We will have to pass the image size explicitly and perform
checks to identify an unsatisfiable byte range request from the
parsed ``Range`` header. This change will also require an API
version bump.
:timeline: Expected to be merged within the Ocata time frame.
:link: https://review.openstack.org/#/c/367528/
:assignee: Dharini Chandrasekar
`End of` Use ``Range`` HTTP header instead of ``Content-Range`` for parsing requests
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

19
specs/ocata/implemented/index.rst Normal file
View File

@ -0,0 +1,19 @@
================================
Ocata Implemented Specifications
================================
.. toctree::
:glob:
:maxdepth: 1
Ocata implemented specs for Glance:
.. toctree::
:glob:
:maxdepth: 1
glance/*
No specs or lite-specs were implemented for glance_store in Ocata.
No specs or lite-specs were implemented for python-glanceclient in Ocata.

2
specs/ocata/index.rst
View File

@ -12,7 +12,7 @@ Ocata implemented specs:
:glob:
:maxdepth: 1
.. implemented/*
implemented/*
Ocata approved (but not implemented) specs: