trivial: Fix typos in release notes

Change-Id: I989fa12f115075c27b29b4863cbb5240abfb5978
This commit is contained in:
Stephen Finucane 2018-01-31 10:38:57 +00:00
parent 870ad2c205
commit bd3da5d763
6 changed files with 37 additions and 40 deletions

View File

@ -9,16 +9,12 @@ features:
used by instances.
For knowing which types the physical GPU driver supports for libvirt, the
operator can look at the sysfs by doing
..
operator can look at the sysfs by doing::
ls /sys/class/mdev_bus/<device>/mdev_supported_types
Operators can specify a VGPU resource in a flavor by adding in the flavor's
extra specs
..
extra specs::
nova flavor-key <flavor-id> set resources:VGPU=1
@ -35,8 +31,8 @@ features:
other instance actions (like snapshotting the instance or shelving it)
are recommended until libvirt supports that. If a user asks to suspend
the instance, Nova will get an exception that will set the instance state
back to ACTIVE, and you can see the suspend action in os-instance-action
API will be Error.
back to ``ACTIVE``, and you can see the suspend action in
``os-instance-action`` API will be Error.
* Resizing an instance with a new flavor that has vGPU resources doesn't
allocate those vGPUs to the instance (the instance is created without
@ -63,12 +59,12 @@ features:
to check if they have mediated devices, and if the mediated device no
longer exists, then Nova recreates it by using the same UUID.
* If you use Nvidia GRID cards, please know that there is a limitation with
the nvidia driver that prevents one guest to have more than one virtual
* If you use NVIDIA GRID cards, please know that there is a limitation with
the NVIDIA driver that prevents one guest to have more than one virtual
GPU from the same physical card. One guest can have two or more virtual
GPUs but then it requires each vGPU to be hosted by a separate physical
card. Until that limitation is removed, please avoid creating flavors
asking for more than 1 vGPU.
asking for more than one vGPU.
We are working actively to remove or workaround those caveats, but please
understand that for the moment this feature is experimental given all the

View File

@ -1,7 +1,7 @@
---
other:
- Adds 'sata' as a valid disk bus for qemu and kvm hypervisors.
Setting the 'hw_disk_bus' custom property on glance images allows for
- Adds ``sata`` as a valid disk bus for qemu and kvm hypervisors.
Setting the ``hw_disk_bus`` custom property on glance images allows for
selecting the type of disk bus e.g. VIRTIO/IDE/SCSI. Some Linux (custom)
images require use of SATA bus rather than any other that seem to be
allowed.

View File

@ -8,19 +8,19 @@ deprecations:
- Show & List detail server
- os_compute_api:os-config-drive
- os_compute_api:os-extended-availability-zone
- os_compute_api:os-extended-status
- os_compute_api:os-extended-volumes
- os_compute_api:os-keypairs
- os_compute_api:os-server-usage
- os_compute_api:os-security-groups (only from /servers APIs)
- ``os_compute_api:os-config-drive``
- ``os_compute_api:os-extended-availability-zone``
- ``os_compute_api:os-extended-status``
- ``os_compute_api:os-extended-volumes``
- ``os_compute_api:os-keypairs``
- ``os_compute_api:os-server-usage``
- ``os_compute_api:os-security-groups`` (only from ``/servers`` APIs)
- Create, Update, Show & List detail flavor
- os_compute_api:os-flavor-rxtx
- os_compute_api:os-flavor-access (only from /flavors APIs)
- ``os_compute_api:os-flavor-rxtx``
- ``os_compute_api:os-flavor-access`` (only from ``/flavors`` APIs)
- Show & List detail image
- os_compute_api:image-size
- ``os_compute_api:image-size``

View File

@ -3,13 +3,13 @@ features:
- |
The following instance action records have been added:
* attach_interface
* detach_interface
* attach_volume
* detach_volume
* swap_volume
* lock
* unlock
* shelveOffload
* createBackup
* createImage
* ``attach_interface``
* ``detach_interface``
* ``attach_volume``
* ``detach_volume``
* ``swap_volume``
* ``lock``
* ``unlock``
* ``shelveOffload``
* ``createBackup``
* ``createImage``

View File

@ -3,8 +3,8 @@ upgrade:
- |
The ``[DEFAULT] vendordata_driver`` option was deprecated in Mitaka and has
now been removed. Configuration of vendordata drivers should now be done by
using the `[api] vendordata_providers`` option. For more information, refer
to the `vendordata documentation`__.
using the ``[api] vendordata_providers`` option. For more information,
refer to the `vendordata documentation`__.
__ https://docs.openstack.org/nova/latest/user/vendordata.html
- |

View File

@ -7,22 +7,23 @@ features:
vGPU types in the nova compute configuration file with the configuration
option - ``[devices]/enabled_vgpu_types``. Only the enabled vGPU types
can be used by instances.
XenServer automatically detects and groups together identical physical
GPUs. Although the physical GPUs may support multiple vGPU types, at
the moment nova only supports a single vGPU type for each compute node.
The operators can run the following CLI commands in XenServer to get
the available vGPU types if the host supports vGPU.
the available vGPU types if the host supports vGPU::
* xe vgpu-type-list
xe vgpu-type-list
The values of "model-name ( RO):" from the output of the above commands
The values of ``model-name ( RO):`` from the output of the above commands
are the vGPU type names which you can choose from to set the nova
configure - ``[devices]/enabled_vgpu_types``. Please choose only one
vGPU type to be enabled.
The operators should specify a vGPU resource in the flavor's extra_specs:
The operators should specify a vGPU resource in the flavor's extra_specs::
* nova flavor-key <flavor-id> set resources:VGPU=1
nova flavor-key <flavor-id> set resources:VGPU=1
Then users can use the flavor to boot instances with a vGPU attached.
At the moment, XenServer doesn't support multiple vGPUs for a single