Update specs repo for Ocata

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

Change-Id: Iba7f85a28115639c520c239d063a54e92ef01a37

specs/ocata/approved/glance/lite-specs.rst

@@ -2,159 +2,8 @@
 Glance Spec Lite
 ================
 
-Please keep this template section in place and add your own copy of it between the markers.
+Replace mox with mock for unit test
-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
-----------------------------------
 
 :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
+`End of` Replace mox with mock for unit test
-++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++
-
-Add your Spec Lite before this line
-===================================

specs/ocata/implemented/glance/lite-specs.rst

@@ -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
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

specs/ocata/implemented/index.rst

@@ -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.

specs/ocata/index.rst

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