This document aims to define how we describe features listed in the Feature Support Matrix.
Warning
Please note: this is a work in progress!
Our users want the features they rely on to be reliable and always continue to solve for their use case. The feature classification matrix should help identify which features are complete and ready to use, and which should be used with caution.
An additional benefit, is we have a clear list of things where we need help to complete the feature, its testing and its documentation.
Below is a matrix for a selection of important verticals:
For more details on the concepts in each matrix, please see Notes on Concepts.
This is a summary of the key features dev/test clouds, and other similar general purpose clouds need, and it describes their current state.
Below there are sections on NFV and HPC specific features. These look at specific features and scenarios that are important to those more specific sets of use cases.
Feature | Maturity | Hyper-V CI | Ironic CI | libvirt+kvm (gate) | libvirt+xen | VMware CI | XenServer CI |
---|---|---|---|---|---|---|---|
Create Server and Delete Server | complete | ? | ? | ? | ? | ? | ? |
Snapshot Server | complete | ? | ? | ? | ? | ? | ? |
Server power ops | complete | ? | ? | ? | ? | ? | ? |
Rebuild Server | complete | ? | ? | ? | ? | ? | ? |
Resize Server | complete | ? | ? | ? | ? | ? | ? |
Volume Operations | complete | ✔ | ✖ | ✔ | ✔ | ✔ | ✔ |
Custom disk configurations on boot | complete | ✔ n | ✖ | ✔ | ✔ | ✔ | ✔ |
Custom neutron configurations on boot | complete | ✔ | ✖ | ✔ | ✔ | ✔ | ✔ |
Pause a Server | complete | ✔ | ✖ | ✔ | ✔ | ✔ | ✔ |
Suspend a Server | complete | ✔ | ✖ | ✔ | ✔ | ✔ | ✔ |
Server console output | complete | ✔ | ✖ | ✔ | ✔ | ✔ | ✔ |
Server Rescue | complete | ✔ | ✖ | ✔ | ✔ | ✔ | ✔ |
Server Config Drive | complete | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
Server Change Password | experimental | ✔ | ✖ | ✔ | ✖ | ✖ | ✔ |
Server Shelve and Unshelve | complete | ✔ | ✖ | ✔ | ✔ | ✖ | ✔ |
This includes creating a server, and deleting a server. Specifically this is about booting a server from a glance image using the default disk and network configuration.
info:
drivers:
This is creating a glance image from the currently running server.
info:
drivers:
This includes reboot, stop and start.
info:
drivers:
You can rebuild a server, optionally specifying the glance image to use.
info:
drivers:
You resize a server to a new flavor, then confirm or revert that operation.
info:
drivers:
This is about attaching volumes, detaching volumes.
info:
drivers:
This is about supporting all the features of BDMv2. This includes booting from a volume, in various ways, and specifying a custom set of ephemeral disks. Note some drivers only supports part of what the API allows.
info:
drivers:
This is about supporting booting from one or more neutron ports, or all the related short cuts such as booting a specified network. This does not include SR-IOV or similar, just simple neutron ports.
info:
drivers:
This is pause and unpause a server, where the state is held in memory.
info:
drivers:
This suspend and resume a server, where the state is held on disk.
info:
drivers:
This gets the current server console output.
info:
drivers:
This boots a server with a new root disk from the specified glance image to allow a user to fix a boot partition configuration, or similar.
info:
drivers:
This ensures the user data provided by the user when booting a server is available in one of the expected config drive locations.
info:
drivers:
The ability to reset the password of a user within the server.
info:
drivers:
The ability to keep a server logically alive, but not using any cloud resources. For local disk based instances, this involves taking a snapshot, called offloading.
info:
drivers:
Network Function Virtualization (NFV) is about virtualizing network node functions into building blocks that may connect, or chain together to create a particular service. It is common for this workloads needing bare metal like performance, i.e. low latency and close to line speed performance.
Feature | Maturity | libvirt+kvm | libvirt+xen |
---|---|---|---|
NUMA Placement | experimental | ✔ m | ✖ |
TODO add notes for feature
info:
drivers:
High Performance Compute (HPC) cloud have some specific needs that are covered in this set of features.
Feature | Maturity | Hyper-V CI | libvirt+kvm (gate) | libvirt+xen | VMware CI | XenServer CI |
---|---|---|---|---|---|---|
GPU Passthrough | experimental | ✖ | ✔ l | ✖ | ✖ | ✔ k |
TODO add notes for feature
info:
drivers:
Some definitions to help understand the later part of the document.
These are the users we will talk about in this document:
Now in reality the picture is way more complex. Specifically, there are likely to be different roles for observer, creator and admin roles for the application developer. Similarly, there are likely to be various levels of cloud operator permissions, some read only, see a subset of tenants, etc.
Note: this is not attempting to be an exhaustive set of personas that consider various facets of the different users, but instead aims to be a minimal set of users, such that we use a consistent terminology throughout this document.
To reduce the size of the matrix, we organize the features into groups. Each group maps to a set of user stories, that can be validated by a set of scenarios, tests. Typically, this means a set of tempest tests.
This list focuses on API concepts like attach and detach volumes, rather than deployment specific concepts like attach iSCSI volume to KVM based VM.
A deployment maps to a specific test environment. A full description of the environment should be provided, so its possible to reproduce the test results that are reported for each of the Feature Groups.
Note: this description includes all aspects of the deployment: the hypervisor, the number of nova-compute services, the storage being used, the network driver being used, the types of images being tested, etc.
The Feature Group Maturity rating is specific to the API concepts, rather than specific to a particular deployment. That detail is covered in the deployment rating for each feature group.
We are starting out these Feature Group ratings:
Incomplete features are those that don’t have enough functionality to satisfy real world use cases.
Experimental features should be used with extreme caution. They are likely to have little or no upstream testing. With little testing there are likely to be many unknown bugs.
For a feature to be considered complete, we must have:
There are various reasons why a feature, once complete, becomes required, but currently its largely when a feature is supported by all drivers. Note that any new drivers need to prove they support all required features before it would be allowed in upstream Nova. Please note that this list is technically unrelated to the DefCore effort, despite there being obvious parallels that could be drawn.
Required features are those that any new technology must support before being allowed into tree. The larger the list, the more features can be expected to be available on all Nova based clouds.
Deprecated features are those that are scheduled to be removed in a future major release of Nova. If a feature is marked as complete, it should never be deprecated. If a feature is incomplete or experimental for several releases, it runs the risk of being deprecated, and later removed from the code base.
The deployment rating is purely about the state of the tests for each Feature Group on a particular deployment.
There will the following ratings:
The eventual goal is to automate this list from some third party CI reporting system, but so we can make progress, this will be a manual inspection that is documented by an hand written ini file. Ideally, this will be reviewed every milestone.