From 2f9646bcd5fd2cf4a1300d960af9cde64179eb9b Mon Sep 17 00:00:00 2001 From: Rikimaru Honjo Date: Mon, 8 Oct 2018 02:48:16 +0000 Subject: [PATCH] Add a feature support matrix This patch adds a feature support matrix of nova-lxd. Items and descriptions of matrix are basically quoted from the support matrix of nova: https://docs.openstack.org/nova/latest/user/support-matrix.html "Block storage over RBD(Ceph)" and "VXLAN networking" are added newly. The nova's matrix contains items other than operation.*. (e.g. networking.*, storage.*, console.*...) But, those items are not appeared in the built html. This is a spec of sphinx_feature_classification.support_matrix: https://docs.openstack.org/sphinx-feature-classification/latest/user/index.html So the matrix added by this patch changed all items to operation.*. Change-Id: Iafb072b32f0d0568e04864afef8e053ab442f41a --- doc/source/conf.py | 1 + doc/source/index.rst | 1 + doc/source/support_matrix/support-matrix.ini | 701 +++++++++++++++++++ doc/source/support_matrix/support-matrix.rst | 16 + lower-constraints.txt | 1 + specs/todo.txt | 119 ---- test-requirements.txt | 1 + 7 files changed, 721 insertions(+), 119 deletions(-) create mode 100644 doc/source/support_matrix/support-matrix.ini create mode 100644 doc/source/support_matrix/support-matrix.rst delete mode 100644 specs/todo.txt diff --git a/doc/source/conf.py b/doc/source/conf.py index 1474297e..ed595db4 100755 --- a/doc/source/conf.py +++ b/doc/source/conf.py @@ -22,6 +22,7 @@ sys.path.insert(0, os.path.abspath('../..')) # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom ones. extensions = [ 'sphinx.ext.autodoc', + 'sphinx_feature_classification.support_matrix', #'sphinx.ext.intersphinx', 'oslosphinx' ] diff --git a/doc/source/index.rst b/doc/source/index.rst index cc0b1c26..fcb1eeca 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -15,6 +15,7 @@ Contents: contributing exclusive_machine vif_wiring + support_matrix/support-matrix Indices and tables ================== diff --git a/doc/source/support_matrix/support-matrix.ini b/doc/source/support_matrix/support-matrix.ini new file mode 100644 index 00000000..16554a88 --- /dev/null +++ b/doc/source/support_matrix/support-matrix.ini @@ -0,0 +1,701 @@ + +# Driver definition +[driver.nova-lxd] +title=Nova-LXD + +# Functions: +[operation.attach-volume] +title=Attach block volume to instance +status=optional +notes=The attach volume operation provides a means to hotplug + additional block storage to a running instance. This allows + storage capabilities to be expanded without interruption of + service. In a cloud model it would be more typical to just + spin up a new instance with large storage, so the ability to + hotplug extra storage is for those cases where the instance + is considered to be more of a pet than cattle. Therefore + this operation is not considered to be mandatory to support. +cli=nova volume-attach +driver.nova-lxd=complete + +[operation.attach-tagged-volume] +title=Attach tagged block device to instance +status=optional +notes=Attach a block device with a tag to an existing server instance. See + "Device tags" for more information. +cli=nova volume-attach [--tag ] +driver.nova-lxd=unknown + +[operation.detach-volume] +title=Detach block volume from instance +status=optional +notes=See notes for attach volume operation. +cli=nova volume-detach +driver.nova-lxd=missing + +[operation.extend-volume] +title=Extend block volume attached to instance +status=optional +notes=The extend volume operation provides a means to extend + the size of an attached volume. This allows volume size + to be expanded without interruption of service. + In a cloud model it would be more typical to just + spin up a new instance with large storage, so the ability to + extend the size of an attached volume is for those cases + where the instance is considered to be more of a pet than cattle. + Therefore this operation is not considered to be mandatory to support. +cli=cinder extend +driver.nova-lxd=unknown + +[operation.attach-interface] +title=Attach virtual network interface to instance +status=optional +notes=The attach interface operation provides a means to hotplug + additional interfaces to a running instance. Hotplug support + varies between guest OSes and some guests require a reboot for + new interfaces to be detected. This operation allows interface + capabilities to be expanded without interruption of service. + In a cloud model it would be more typical to just spin up a + new instance with more interfaces. +cli=nova interface-attach +driver.nova-lxd=complete + +[operation.attach-tagged-interface] +title=Attach tagged virtual network interface to instance +status=optional +notes=Attach a virtual network interface with a tag to an existing + server instance. See "Device tags" for more information. +cli=nova interface-attach [--tag ] +driver.nova-lxd=unknown + +[operation.detach-interface] +title=Detach virtual network interface from instance +status=optional +notes=See notes for attach-interface operation. +cli=nova interface-detach +driver.nova-lxd=complete + +[operation.maintenance-mode] +title=Set the host in a maintenance mode +status=optional +notes=This operation allows a host to be placed into maintenance + mode, automatically triggering migration of any running + instances to an alternative host and preventing new + instances from being launched. This is not considered + to be a mandatory operation to support. + The driver methods to implement are "host_maintenance_mode" and + "set_host_enabled". +cli=nova host-update +driver.nova-lxd=unknown + +[operation.evacuate] +title=Evacuate instances from a host +status=optional +notes=A possible failure scenario in a cloud environment is the outage + of one of the compute nodes. In such a case the instances of the down + host can be evacuated to another host. It is assumed that the old host + is unlikely ever to be powered back on, otherwise the evacuation + attempt will be rejected. When the instances get moved to the new + host, their volumes get re-attached and the locally stored data is + dropped. That happens in the same way as a rebuild. + This is not considered to be a mandatory operation to support. +cli=nova evacuate ;nova host-evacuate +driver.nova-lxd=complete + +[operation.rebuild] +title=Rebuild instance +status=optional +notes=A possible use case is additional attributes need to be set + to the instance, nova will purge all existing data from the system + and remakes the VM with given information such as 'metadata' and + 'personalities'. Though this is not considered to be a mandatory + operation to support. +cli=nova rebuild +driver.nova-lxd=complete + +[operation.get-guest-info] +title=Guest instance status +status=mandatory +notes=Provides realtime information about the power state of the guest + instance. Since the power state is used by the compute manager for + tracking changes in guests, this operation is considered mandatory to + support. +cli= +driver.nova-lxd=unknown + +[operation.get-host-uptime] +title=Guest host uptime +status=optional +notes=Returns the result of host uptime since power on, + it's used to report hypervisor status. +cli= +driver.nova-lxd=unknown + +[operation.get-host-ip] +title=Guest host ip +status=optional +notes=Returns the ip of this host, it's used when doing + resize and migration. +cli= +driver.nova-lxd=unknown + +[operation.live-migrate] +title=Live migrate instance across hosts +status=optional +notes=Live migration provides a way to move an instance off one + compute host, to another compute host. Administrators may use + this to evacuate instances from a host that needs to undergo + maintenance tasks, though of course this may not help if the + host is already suffering a failure. In general instances are + considered cattle rather than pets, so it is expected that an + instance is liable to be killed if host maintenance is required. + It is technically challenging for some hypervisors to provide + support for the live migration operation, particularly those + built on the container based virtualization. Therefore this + operation is not considered mandatory to support. +cli=nova live-migration ;nova host-evacuate-live +driver.nova-lxd=complete + +[operation.force-live-migration-to-complete] +title=Force live migration to complete +status=optional +notes=Live migration provides a way to move a running instance to another + compute host. But it can sometimes fail to complete if an instance has + a high rate of memory or disk page access. + This operation provides the user with an option to assist the progress + of the live migration. The mechanism used to complete the live + migration depends on the underlying virtualization subsystem + capabilities. If libvirt/qemu is used and the post-copy feature is + available and enabled then the force complete operation will cause + a switch to post-copy mode. Otherwise the instance will be suspended + until the migration is completed or aborted. +cli=nova live-migration-force-complete +driver.nova-lxd=unknown + +[operation.launch] +title=Launch instance +status=mandatory +notes=Importing pre-existing running virtual machines on a host is + considered out of scope of the cloud paradigm. Therefore this + operation is mandatory to support in drivers. +cli= +driver.nova-lxd=unknown + +[operation.pause] +title=Stop instance CPUs (pause) +status=optional +notes=Stopping an instances CPUs can be thought of as roughly + equivalent to suspend-to-RAM. The instance is still present + in memory, but execution has stopped. The problem, however, + is that there is no mechanism to inform the guest OS that + this takes place, so upon unpausing, its clocks will no + longer report correct time. For this reason hypervisor vendors + generally discourage use of this feature and some do not even + implement it. Therefore this operation is considered optional + to support in drivers. +cli=nova pause +driver.nova-lxd=complete + +[operation.reboot] +title=Reboot instance +status=optional +notes=It is reasonable for a guest OS administrator to trigger a + graceful reboot from inside the instance. A host initiated + graceful reboot requires guest co-operation and a non-graceful + reboot can be achieved by a combination of stop+start. Therefore + this operation is considered optional. +cli=nova reboot +driver.nova-lxd=complete + +[operation.rescue] +title=Rescue instance +status=optional +notes=The rescue operation starts an instance in a special + configuration whereby it is booted from an special root + disk image. The goal is to allow an administrator to + recover the state of a broken virtual machine. In general + the cloud model considers instances to be cattle, so if + an instance breaks the general expectation is that it be + thrown away and a new instance created. Therefore this + operation is considered optional to support in drivers. +cli=nova rescue +driver.nova-lxd=complete + +[operation.resize] +title=Resize instance +status=optional +notes=The resize operation allows the user to change a running + instance to match the size of a different flavor from the one + it was initially launched with. There are many different + flavor attributes that potentially need to be updated. In + general it is technically challenging for a hypervisor to + support the alteration of all relevant config settings for a + running instance. Therefore this operation is considered + optional to support in drivers. +cli=nova resize +driver.nova-lxd=missing + +[operation.resume] +title=Restore instance +status=optional +notes=See notes for the suspend operation +cli=nova resume +driver.nova-lxd=complete + +[operation.set-admin-password] +title=Set instance admin password +status=optional +notes=Provides a mechanism to (re)set the password of the administrator + account inside the instance operating system. This requires that the + hypervisor has a way to communicate with the running guest operating + system. Given the wide range of operating systems in existence it is + unreasonable to expect this to be practical in the general case. The + configdrive and metadata service both provide a mechanism for setting + the administrator password at initial boot time. In the case where this + operation were not available, the administrator would simply have to + login to the guest and change the password in the normal manner, so + this is just a convenient optimization. Therefore this operation is + not considered mandatory for drivers to support. +cli=nova set-password +driver.nova-lxd=unknown + +[operation.snapshot] +title=Save snapshot of instance disk +status=optional +notes=The snapshot operation allows the current state of the + instance root disk to be saved and uploaded back into the + glance image repository. The instance can later be booted + again using this saved image. This is in effect making + the ephemeral instance root disk into a semi-persistent + storage, in so much as it is preserved even though the guest + is no longer running. In general though, the expectation is + that the root disks are ephemeral so the ability to take a + snapshot cannot be assumed. Therefore this operation is not + considered mandatory to support. +cli=nova image-create +driver.nova-lxd=complete + +[operation.suspend] +title=Suspend instance +status=optional +notes=Suspending an instance can be thought of as roughly + equivalent to suspend-to-disk. The instance no longer + consumes any RAM or CPUs, with its live running state + having been preserved in a file on disk. It can later + be restored, at which point it should continue execution + where it left off. As with stopping instance CPUs, it suffers from the fact + that the guest OS will typically be left with a clock that + is no longer telling correct time. For container based + virtualization solutions, this operation is particularly + technically challenging to implement and is an area of + active research. This operation tends to make more sense + when thinking of instances as pets, rather than cattle, + since with cattle it would be simpler to just terminate + the instance instead of suspending. Therefore this operation + is considered optional to support. +cli=nova suspend +driver.nova-lxd=complete + +[operation.swap-volume] +title=Swap block volumes +status=optional +notes=The swap volume operation is a mechanism for changing a running + instance so that its attached volume(s) are backed by different + storage in the host. An alternative to this would be to simply + terminate the existing instance and spawn a new instance with the + new storage. In other words this operation is primarily targeted towards + the pet use case rather than cattle, however, it is required for volume + migration to work in the volume service. This is considered optional to + support. +cli=nova volume-update +driver.nova-lxd=missing + +[operation.terminate] +title=Shutdown instance +status=mandatory +notes=The ability to terminate a virtual machine is required in + order for a cloud user to stop utilizing resources and thus + avoid indefinitely ongoing billing. Therefore this operation + is mandatory to support in drivers. +cli=nova delete +driver.nova-lxd=complete + +[operation.trigger-crash-dump] +title=Trigger crash dump +status=optional +notes=The trigger crash dump operation is a mechanism for triggering + a crash dump in an instance. The feature is typically implemented by + injecting an NMI (Non-maskable Interrupt) into the instance. It provides + a means to dump the production memory image as a dump file which is useful + for users. Therefore this operation is considered optional to support. +cli=nova trigger-crash-dump +driver.nova-lxd=unknown + +[operation.unpause] +title=Resume instance CPUs (unpause) +status=optional +notes=See notes for the "Stop instance CPUs" operation +cli=nova unpause +driver.nova-lxd=unknown + +[operation.guest.disk.autoconfig] +title=[Guest]Auto configure disk +status=optional +notes=Partition and resize FS to match the size specified by + flavors.root_gb, As this is hypervisor specific feature. + Therefore this operation is considered optional to support. +cli= +driver.nova-lxd=complete + +[operation.guest.disk.rate-limit] +title=[Guest]Instance disk I/O limits +status=optional +notes=The ability to set rate limits on virtual disks allows for + greater performance isolation between instances running on the + same host storage. It is valid to delegate scheduling of I/O + operations to the hypervisor with its default settings, instead + of doing fine grained tuning. Therefore this is not considered + to be an mandatory configuration to support. +cli=nova limits +driver.nova-lxd=unknown + +[operation.guest.setup.configdrive] +title=[Guest]Config drive support +status=choice(guest.setup) +notes=The config drive provides an information channel into + the guest operating system, to enable configuration of the + administrator password, file injection, registration of + SSH keys, etc. Since cloud images typically ship with all + login methods locked, a mechanism to set the administrator + password or keys is required to get login access. Alternatives + include the metadata service and disk injection. At least one + of the guest setup mechanisms is required to be supported by + drivers, in order to enable login access. +cli= +driver.nova-lxd=complete + +[operation.guest.setup.inject.file] +title=[Guest]Inject files into disk image +status=optional +notes=This allows for the end user to provide data for multiple + files to be injected into the root filesystem before an instance + is booted. This requires that the compute node understand the + format of the filesystem and any partitioning scheme it might + use on the block device. This is a non-trivial problem considering + the vast number of filesystems in existence. The problem of injecting + files to a guest OS is better solved by obtaining via the metadata + service or config drive. Therefore this operation is considered + optional to support. +cli= +driver.nova-lxd=unknown + +[operation.guest.setup.inject.networking] +title=[Guest]Inject guest networking config +status=optional +notes=This allows for static networking configuration (IP + address, netmask, gateway and routes) to be injected directly + into the root filesystem before an instance is booted. This + requires that the compute node understand how networking is + configured in the guest OS which is a non-trivial problem + considering the vast number of operating system types. The + problem of configuring networking is better solved by DHCP + or by obtaining static config via + config drive. Therefore this operation is considered optional + to support. +cli= +driver.nova-lxd=unknown + +[operation.console.rdp] +title=[Console]Remote desktop over RDP +status=choice(console) +notes=This allows the administrator to interact with the graphical + console of the guest OS via RDP. This provides a way to see boot + up messages and login to the instance when networking configuration + has failed, thus preventing a network based login. Some operating + systems may prefer to emit messages via the serial console for + easier consumption. Therefore support for this operation is not + mandatory, however, a driver is required to support at least one + of the listed console access operations. +cli=nova get-rdp-console +driver.nova-lxd=missing + +[operation.console.serial.log] +title=[Console]View serial console logs +status=choice(console) +notes=This allows the administrator to query the logs of data + emitted by the guest OS on its virtualized serial port. For + UNIX guests this typically includes all boot up messages and + so is useful for diagnosing problems when an instance fails + to successfully boot. Not all guest operating systems will be + able to emit boot information on a serial console, others may + only support graphical consoles. Therefore support for this + operation is not mandatory, however, a driver is required to + support at least one of the listed console access operations. +cli=nova console-log +driver.nova-lxd=complete + +[operation.console.serial.interactive] +title=[Console]Remote interactive serial console +status=choice(console) +notes=This allows the administrator to interact with the serial + console of the guest OS. This provides a way to see boot + up messages and login to the instance when networking configuration + has failed, thus preventing a network based login. Not all guest + operating systems will be able to emit boot information on a serial + console, others may only support graphical consoles. Therefore support + for this operation is not mandatory, however, a driver is required to + support at least one of the listed console access operations. + This feature was introduced in the Juno release with blueprint + https://blueprints.launchpad.net/nova/+spec/serial-ports +cli=nova get-serial-console +driver.nova-lxd=unknown + +[operation.console.spice] +title=[Console]Remote desktop over SPICE +status=choice(console) +notes=This allows the administrator to interact with the graphical + console of the guest OS via SPICE. This provides a way to see boot + up messages and login to the instance when networking configuration + has failed, thus preventing a network based login. Some operating + systems may prefer to emit messages via the serial console for + easier consumption. Therefore support for this operation is not + mandatory, however, a driver is required to support at least one + of the listed console access operations. +cli=nova get-spice-console +driver.nova-lxd=missing + +[operation.console.vnc] +title=[Console]Remote desktop over VNC +status=choice(console) +notes=This allows the administrator to interact with the graphical + console of the guest OS via VNC. This provides a way to see boot + up messages and login to the instance when networking configuration + has failed, thus preventing a network based login. Some operating + systems may prefer to emit messages via the serial console for + easier consumption. Therefore support for this operation is not + mandatory, however, a driver is required to support at least one + of the listed console access operations. +cli=nova get-vnc-console +driver.nova-lxd=missing + +[operation.storage.block] +title=[Storage]Block storage support +status=optional +notes=Block storage provides instances with direct attached + virtual disks that can be used for persistent storage of data. + As an alternative to direct attached disks, an instance may + choose to use network based persistent storage. OpenStack provides + object storage via the Swift service, or a traditional filesystem + such as NFS may be used. Some types of instances may + not require persistent storage at all, being simple transaction + processing systems reading requests & sending results to and from + the network. Therefore support for this configuration is not + considered mandatory for drivers to support. +cli= +driver.nova-lxd=partial +driver-notes.nova-lxd=Booting instances from block storages is not supported. + +[operation.storage.block.backend.fibrechannel] +title=[Storage]Block storage over fibre channel +status=optional +notes=To maximise performance of the block storage, it may be desirable + to directly access fibre channel LUNs from the underlying storage + technology on the compute hosts. Since this is just a performance + optimization of the I/O path it is not considered mandatory to support. +cli= +driver.nova-lxd=unknown + +[operation.storage.block.backend.iscsi] +title=[Storage]Block storage over iSCSI +status=condition(storage.block==complete) +notes=If the driver wishes to support block storage, it is common to + provide an iSCSI based backend to access the storage from cinder. + This isolates the compute layer for knowledge of the specific storage + technology used by Cinder, albeit at a potential performance cost due + to the longer I/O path involved. If the driver chooses to support + block storage, then this is considered mandatory to support, otherwise + it is considered optional. +cli= +driver.nova-lxd=complete + +[operation.storage.block.backend.iscsi.auth.chap] +title=[Storage]CHAP authentication for iSCSI +status=optional +notes=If accessing the cinder iSCSI service over an untrusted LAN it + is desirable to be able to enable authentication for the iSCSI + protocol. CHAP is the commonly used authentication protocol for + iSCSI. This is not considered mandatory to support. (?) +cli= +driver.nova-lxd=unknown + +[operation.storage.block.ceph] +title=[Storage]Block storage over RBD(Ceph) +status=condition(storage.block==complete) +notes=Ceph is an open source software storage platform based upon RADOS. + Instances can access to the ceph storage cluster by ceph's RBD(RADOS + Block Device). +cli= +driver.nova-lxd=complete + +[operation.storage.image] +title=[Storage]Image storage support +status=mandatory +notes=This refers to the ability to boot an instance from an image + stored in the glance image repository. Without this feature it + would not be possible to bootstrap from a clean environment, since + there would be no way to get block volumes populated and reliance + on external PXE servers is out of scope. Therefore this is considered + a mandatory storage feature to support. +cli=nova boot --image +driver.nova-lxd=complete + +[operation.networking.firewallrules] +title=[Networking]Network firewall rules +status=optional +notes=Unclear how this is different from security groups +cli= +driver.nova-lxd=complete + +[operation.networking.routing] +title=Network routing +status=optional +notes=Unclear what this refers to +cli= +driver.nova-lxd=complete + +[operation.networking.securitygroups] +title=[Networking]Network security groups +status=optional +notes=The security groups feature provides a way to define rules + to isolate the network traffic of different instances running + on a compute host. This would prevent actions such as MAC and + IP address spoofing, or the ability to setup rogue DHCP servers. + In a private cloud environment this may be considered to be a + superfluous requirement. Therefore this is considered to be an + optional configuration to support. +cli= +driver.nova-lxd=complete + +[operation.networking.topology.flat] +title=[Networking]Flat networking +status=choice(networking.topology) +notes=Provide network connectivity to guests using a + flat topology across all compute nodes. At least one + of the networking configurations is mandatory to + support in the drivers. +cli= +driver.nova-lxd=complete + +[operation.networking.topology.vlan] +title=[Networking]VLAN networking +status=choice(networking.topology) +notes=Provide network connectivity to guests using VLANs to define the + topology. At least one of the networking configurations is mandatory + to support in the drivers. +cli= +driver.nova-lxd=complete + +[operation.networking.topology.vxlan] +title=[Networking]VXLAN networking +status=choice(networking.topology) +notes=Provide network connectivity to guests using VXLANs to define the + topology. At least one of the networking configurations is mandatory + to support in the drivers. +cli= +driver.nova-lxd=complete + +[operation.uefi-boot] +title=uefi boot +status=optional +notes=This allows users to boot a guest with uefi firmware. +cli= +driver.nova-lxd=unknown + +[operation.device-tags] +title=Device tags +status=optional +notes=This allows users to set tags on virtual devices when creating a + server instance. Device tags are used to identify virtual device + metadata, as exposed in the metadata API and on the config drive. + For example, a network interface tagged with "nic1" will appear in + the metadata along with its bus (ex: PCI), bus address + (ex: 0000:00:02.0), MAC address, and tag (nic1). If multiple networks + are defined, the order in which they appear in the guest operating + system will not necessarily reflect the order in which they are given + in the server boot request. Guests should therefore not depend on + device order to deduce any information about their network devices. + Instead, device role tags should be used. Device tags can be + applied to virtual network interfaces and block devices. +cli=nova boot +driver.nova-lxd=unknown + +[operation.quiesce] +title=quiesce +status=optional +notes=Quiesce the specified instance to prepare for snapshots. + For libvirt, guest filesystems will be frozen through qemu + agent. +cli= +driver.nova-lxd=unknown + +[operation.unquiesce] +title=unquiesce +status=optional +notes=See notes for the quiesce operation +cli= +driver.nova-lxd=unknown + +[operation.multiattach-volume] +title=Attach block volume to multiple instances +status=optional +notes=The multiattach volume operation is an extension to + the attach volume operation. It allows to attach a + single volume to multiple instances. This operation is + not considered to be mandatory to support. + Note that for the libvirt driver, this is only supported + if qemu<2.10 or libvirt>=3.10. +cli=nova volume-attach +driver.nova-lxd=unknown + +[operation.encrypted-volume] +title=Attach encrypted block volume to server +status=optional +notes=This is the same as the attach volume operation + except with an encrypted block device. Encrypted + volumes are controlled via admin-configured volume + types in the block storage service. Since attach + volume is optional this feature is also optional for + compute drivers to support. +cli=nova volume-attach +driver.nova-lxd=unknown + +[operation.trusted-certs] +title=Validate image with trusted certificates +status=optional +notes=Since trusted image certification validation is configurable + by the cloud deployer it is considered optional. However, it is + a virt-agnostic feature so there is no good reason that all virt + drivers cannot support the feature since it is mostly just plumbing + user requests through the virt driver when downloading images. +cli=nova boot --trusted-image-certificate-id ... +driver.nova-lxd=unknown + +[operation.file-backed-memory] +title=File backed memory +status=optional +notes=The file backed memory feature in Openstack allows a Nova node to serve + guest memory from a file backing store. This mechanism uses the libvirt + file memory source, causing guest instance memory to be allocated as files + within the libvirt memory backing directory. This is only supported if + qemu>2.6 and libivrt>4.0.0 +cli= +driver.nova-lxd=unknown + +[operation.report-cpu-traits] +title=Report CPU traits +status=optional +notes=The report CPU traits feature in OpenStack allows a Nova node to report + its CPU traits according to CPU mode configuration. This gives users the ability + to boot instances based on desired CPU traits. +cli= +driver.nova-lxd=unknown diff --git a/doc/source/support_matrix/support-matrix.rst b/doc/source/support_matrix/support-matrix.rst new file mode 100644 index 00000000..5227fc77 --- /dev/null +++ b/doc/source/support_matrix/support-matrix.rst @@ -0,0 +1,16 @@ +=============================== +Nova-lxd Feature Support Matrix +=============================== + +The following support matrix reflects the nova-lxd that is currently available +or is available at the time of release. + +.. Note:: + + Notes for each operation of this matrix were basically quoted from + `support-matrix of Nova `_. + + +.. _driver_support_matrix: + +.. support_matrix:: support-matrix.ini diff --git a/lower-constraints.txt b/lower-constraints.txt index bb898935..5bebaebe 100644 --- a/lower-constraints.txt +++ b/lower-constraints.txt @@ -92,6 +92,7 @@ Routes==2.4.1 six==1.11.0 snowballstemmer==1.2.1 Sphinx==1.6.5 +sphinx-feature-classification==0.1.0 sphinxcontrib-websupport==1.0.1 statsd==3.2.2 stestr==1.0.0 diff --git a/specs/todo.txt b/specs/todo.txt deleted file mode 100644 index a51b85c0..00000000 --- a/specs/todo.txt +++ /dev/null @@ -1,119 +0,0 @@ -nova-lxd todo list - -Taken from https://docs.openstack.org/nova/latest/support-matrix.html - -Feature Status Kilo Liberty -Attach block optional X not started -volume to -instance ------------------------------------------------------- -Detach block optional X not started -volume from -instance ------------------------------------------------------- -Evacuate optional X complete -instances -from host --------------------------------------------------------- -Guest instance mandatory started started -status --------------------------------------------------------- -Gust host optional started started -status --------------------------------------------------------- -Live migrate optional X not started -instance -across hosts ---------------------------------------------------------- -Launch mandatory complete complete -instance --------------------------------------------------------- -Stop instance optional complete complete -CPUs --------------------------------------------------------- -Reboot optional complete complete -instance --------------------------------------------------------- -Rescue optional X complete -instance --------------------------------------------------------- -Resize optional X not started -instance --------------------------------------------------------- -Restore optional X complete -instance --------------------------------------------------------- -Service optional X not started -control (??) --------------------------------------------------------- -Set instance optional X not started -admin -password --------------------------------------------------------- -Save snapshot optional X complete -of instance disk --------------------------------------------------------- -Swap block optional X not applicable -volumes ------------------------------------------------------------ -Shutdown mandatory complete complete -instance ------------------------------------------------------------ -Resume optional X not applicable -insance -CPUs ----------------------------------------------------------- -Config drive choice X complete -support ----------------------------------------------------------- -inject files optional X not started -into disk -image ---------------------------------------------------------- -inject guest optional X not started -networking -config ---------------------------------------------------------- -Remote choice X not applicable -desktop over -RDP ----------------------------------------------------------- -View serial choice complete complete -console logs ----------------------------------------------------------- -Remote choice X not applicable -desktp over -SPICE ------------------------------------------------------------ -Remote choice X not applicable -desktop over -VNC ----------------------------------------------------------- -Block storage optional X not started -support ---------------------------------------------------------- -Block storage optional X not started -over iSCSI ---------------------------------------------------------- -CHAP optional X not started -authenication -for iSCIS ---------------------------------------------------------- -Image storage mandatory complete complete -support ---------------------------------------------------------- -Network optional X complete -firewall rules ---------------------------------------------------------- -Network optional complete complete -routing ---------------------------------------------------------- -Network optional X complete -security -groups ---------------------------------------------------------- -Flat choice complete complete -networking --------------------------------------------------------- -VLAN choice complete complete -networking diff --git a/test-requirements.txt b/test-requirements.txt index b5958e0e..909fd418 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -8,6 +8,7 @@ coverage!=4.4,>=4.5.1 # Apache-2.0 ddt>=1.1.2 # MIT python-subunit>=1.2.0 # Apache-2.0/BSD sphinx!=1.6.6,!=1.6.7,>=1.6.5 # BSD +sphinx-feature-classification>=0.1.0 # Apache 2.0 oslosphinx>=4.18.0 # Apache-2.0 oslotest>=3.3.0 # Apache-2.0 testrepository>=0.0.20 # Apache-2.0/BSD