nova/doc/source/support-matrix.rst
Daniel P. Berrange 4837c42127 Add formal doc recording hypervisor feature capability matrix
Add document to replace / obsolete the giant table on

  https://wiki.openstack.org/wiki/HypervisorSupportMatrix

This initial draft is a fairly straightforward conversion of
that table. Over time, it needs much work to improve the coverage
of API operations and and coverage of important configuration
information that users will care about.

It is using the .ini file syntax in order to record the data in
an easily machine parsable format, while remaining human friendly
by avoiding the syntax heavy approach of XML / JSON / YAML

An extension is registered with sphinx that can convert the
.ini file content into docutils content that then gets rendered
into the developer docs, linked from the index page

Change-Id: I4d3db4bce5737dba30a026a11083a9ea64459cd4
2015-02-03 15:15:49 +00:00

1.7 KiB

Hypervisor Support Matrix

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.