2f0b8df9bf
This effort is trying to ensure we better document what is currently tested and know to work, and what is not currently tested. This renames the Hypervisor support matrix, to the Feature support matrix. The vision is to move the support matrix ticks to appear only for features that have tests passing. To enable this to happen, the column will change from being the virt driver, to being a specific combination of technologies (such as libvirt + KVM + ceph + neutron ML2 with ovs) The second step is to include information about the maturity of the specific feature that is being tested. This will mean the matrix rows will instead reference a feature group, that has an associated list of tempest test uuid and links to detailed API docs. Change-Id: Ia2d489cb4e1fd57737468df4f9fc10e9ad8c011c
43 lines
1.9 KiB
ReStructuredText
43 lines
1.9 KiB
ReStructuredText
|
|
Feature Support Matrix
|
|
======================
|
|
|
|
.. warning::
|
|
Please note, while this document is still being maintained, this is slowly
|
|
being updated to re-group and classify features using the definitions
|
|
described in here: :doc:`feature_classification`
|
|
|
|
When considering which capabilities should be marked as mandatory the
|
|
following general guiding principles were applied
|
|
|
|
* **Inclusivity** - people have shown ability to make effective
|
|
use of a wide range of virtualization technologies with broadly
|
|
varying featuresets. Aiming to keep the requirements as inclusive
|
|
as possible, avoids second-guessing what a user may wish to use
|
|
the cloud compute service for.
|
|
|
|
* **Bootstrapping** - a practical use case test is to consider that
|
|
starting point for the compute deploy is an empty data center
|
|
with new machines and network connectivity. The look at what
|
|
are the minimum features required of a compute service, in order
|
|
to get user instances running and processing work over the
|
|
network.
|
|
|
|
* **Competition** - an early leader in the cloud compute service space
|
|
was Amazon EC2. A sanity check for whether a feature should be
|
|
mandatory is to consider whether it was available in the first
|
|
public release of EC2. This had quite a narrow featureset, but
|
|
none the less found very high usage in many use cases. So it
|
|
serves to illustrate that many features need not be considered
|
|
mandatory in order to get useful work done.
|
|
|
|
* **Reality** - there are many virt drivers currently shipped with
|
|
Nova, each with their own supported feature set. Any feature which is
|
|
missing in at least one virt driver that is already in-tree, must
|
|
by inference be considered optional until all in-tree drivers
|
|
support it. This does not rule out the possibility of a currently
|
|
optional feature becoming mandatory at a later date, based on other
|
|
principles above.
|
|
|
|
.. support_matrix::
|