Add Ocata Priorities
Create ocata "high priority" specs list and add the first spec which was agreed as high priority. Change-Id: Ie7d3e560406574abea2e06abe6a5910c577ebdde
This commit is contained in:
parent
2b1e50817f
commit
663fd14551
@ -1,7 +1,20 @@
|
||||
.. manila-specs documentation master file, created by
|
||||
sphinx-quickstart on Tue Jul 9 22:26:36 2013.
|
||||
You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
.. manila-specs
|
||||
|
||||
==============================
|
||||
OpenStack Manila Project Plans
|
||||
==============================
|
||||
|
||||
Priorities
|
||||
==========
|
||||
|
||||
The team agrees to focus review attention on high priority specs starting in
|
||||
the Ocata release. The agreed upon specs are listed here:
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
priorities/*
|
||||
|
||||
Newton approved specs
|
||||
=====================
|
||||
@ -12,19 +25,17 @@ Newton approved specs
|
||||
|
||||
specs/newton/*
|
||||
|
||||
manila-specs Repository Information
|
||||
===================================
|
||||
Specs Process and Repository Information
|
||||
========================================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
README <readme>
|
||||
contributing
|
||||
Process and Deadlines for Specs <specs/specs_deadlines>
|
||||
Spec Template <specs/template>
|
||||
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
* :ref:`search`
|
||||
|
||||
|
1
doc/source/priorities
Symbolic link
1
doc/source/priorities
Symbolic link
@ -0,0 +1 @@
|
||||
../../priorities/
|
33
priorities/ocata-priorities.rst
Normal file
33
priorities/ocata-priorities.rst
Normal file
@ -0,0 +1,33 @@
|
||||
.. _ocata-priorities:
|
||||
|
||||
========================
|
||||
Ocata Project Priorities
|
||||
========================
|
||||
|
||||
List of themes (in the form of use cases) the manila development team is
|
||||
prioritizing in Ocata (in no particular order).
|
||||
|
||||
+-------------------------------------------+-----------------------+
|
||||
| Priority | Primary Contacts |
|
||||
+===========================================+=======================+
|
||||
| `Scenario Tests`_ | `Valeriy Ponomaryov`_ |
|
||||
+-------------------------------------------+-----------------------+
|
||||
|
||||
.. _Valeriy Ponomaryov: https://launchpad.net/~vponomaryov
|
||||
|
||||
Scenario Tests
|
||||
--------------
|
||||
|
||||
History has shown that CI without scenario tests is inadequate because some
|
||||
CI systems are able to pass the existing functional tests while having
|
||||
serious bugs.
|
||||
|
||||
Also lack of clarity about how certain driver operations should work or
|
||||
which operations are required has led to driver that work incorrectly
|
||||
despite good testing work by the original author. Scenario tests should
|
||||
provide a way for driver authors to run a "conformance test" to validate
|
||||
that their drivers do indeed meet community standards.
|
||||
|
||||
To address these two issues we plan to implement new scenario tests to
|
||||
address coverage gaps and also to request that 3rd party CI systems start
|
||||
running the scenario tests suite in addition to the functional test suite.
|
Loading…
Reference in New Issue
Block a user