Merge "doc: Start using openstackdoctheme's extlink extension"
This commit is contained in:
commit
d741f624c8
@ -277,3 +277,9 @@ pdf_documents = [
|
||||
('index', u'ComputeAPIGuide', u'Compute API Guide', u'OpenStack '
|
||||
'contributors')
|
||||
]
|
||||
|
||||
# -- Options for openstackdocstheme -------------------------------------------
|
||||
|
||||
openstack_projects = [
|
||||
'nova',
|
||||
]
|
||||
|
@ -247,8 +247,7 @@ on compute hosts rather than servers.
|
||||
|
||||
- **Aggregates**
|
||||
|
||||
See `Aggregates developer information
|
||||
<https://docs.openstack.org/nova/latest/user/aggregates.html>`_.
|
||||
See :nova-doc:`Aggregates Developer Information <user/aggregates.html>`.
|
||||
|
||||
- **Migrations**
|
||||
|
||||
|
@ -90,7 +90,7 @@ are exposed to administrators:
|
||||
there is no ongoing compute API calls (running tasks), vm_state should reflect
|
||||
what the customer expect the VM to be. When combined with task states,
|
||||
a better picture can be formed regarding the server's health and progress.
|
||||
Please see: `VM States <https://docs.openstack.org/nova/latest/reference/vm-states.html>`_.
|
||||
Refer to :nova-doc:`VM States <reference/vm-states.html>`.
|
||||
|
||||
- task_state represents what is happening to the instance at the
|
||||
current moment. These tasks can be generic, such as 'spawning', or specific,
|
||||
@ -613,17 +613,15 @@ TODO: Add description about how to custom scheduling policy for server booting.
|
||||
Server Consoles
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Server Consoles can also be supplied after server launched.
|
||||
There are several server console services available.
|
||||
First, users can get the console output from the specified server
|
||||
and can limit the lines of console text by setting the length.
|
||||
Second, users can access multiple types of remote consoles.
|
||||
The user can use novnc, xvpvnc, rdp-html5, spice-html5, serial,
|
||||
and webmks(start from microversion 2.8) through either the OpenStack
|
||||
dashboard or the command line. Please see `Configure remote console access
|
||||
<https://docs.openstack.org/nova/latest/admin/remote-console-access.html>`_.
|
||||
Specifically for Xenserver, it provides the ability to create,
|
||||
delete, detail, list specified server vnc consoles.
|
||||
Server Consoles can also be supplied after server launched. There are several
|
||||
server console services available. First, users can get the console output
|
||||
from the specified server and can limit the lines of console text by setting
|
||||
the length. Second, users can access multiple types of remote consoles. The
|
||||
user can use novnc, xvpvnc, rdp-html5, spice-html5, serial, and webmks(start
|
||||
from microversion 2.8) through either the OpenStack dashboard or the command
|
||||
line. Refer to :nova-doc:`Configure remote console access
|
||||
<admin/remote-console-access.html>`. Specifically for Xenserver, it provides
|
||||
the ability to create, delete, detail, list specified server vnc consoles.
|
||||
|
||||
Server networks
|
||||
~~~~~~~~~~~~~~~
|
||||
@ -884,8 +882,8 @@ Metadata API
|
||||
------------
|
||||
Nova provides a metadata api for servers to retrieve server specific metadata.
|
||||
Neutron ensures this metadata api can be accessed through a predefined ip
|
||||
address (169.254.169.254). For more details, see
|
||||
`Metadata Service <https://docs.openstack.org/nova/latest/user/metadata-service.html>`_.
|
||||
address (169.254.169.254). For more details, see :nova-doc:`Metadata Service
|
||||
<user/metadata-service.html>`.
|
||||
|
||||
Config Drive
|
||||
------------
|
||||
@ -893,8 +891,8 @@ Config Drive
|
||||
Nova is able to write metadata to a special configuration drive that attaches
|
||||
to the server when it boots. The server can mount this drive and read files
|
||||
from it to get information that is normally available through the metadata
|
||||
service. For more details, see
|
||||
`Config Drive <https://docs.openstack.org/nova/latest/user/config-drive.html>`_.
|
||||
service. For more details, see :nova-doc:`Config Drive
|
||||
<user/config-drive.html>`.
|
||||
|
||||
User data
|
||||
---------
|
||||
|
@ -5,7 +5,7 @@ sphinx!=1.6.6,!=1.6.7,>=1.6.2 # BSD
|
||||
sphinxcontrib-actdiag>=0.8.5 # BSD
|
||||
sphinxcontrib-seqdiag>=0.8.4 # BSD
|
||||
os-api-ref>=1.4.0 # Apache-2.0
|
||||
openstackdocstheme>=1.18.1 # Apache-2.0
|
||||
openstackdocstheme>=1.19.0 # Apache-2.0
|
||||
|
||||
# releasenotes
|
||||
reno>=2.5.0 # Apache-2.0
|
||||
|
@ -49,7 +49,7 @@ support across different hypervisors, see :doc:`/user/support-matrix`.
|
||||
You can also orchestrate clouds using multiple hypervisors in different
|
||||
availability zones. Compute supports the following hypervisors:
|
||||
|
||||
- `Baremetal <https://docs.openstack.org/ironic/latest/>`__
|
||||
- :ironic-doc:`Baremetal <>`
|
||||
|
||||
- `Docker <https://www.docker.io>`__
|
||||
|
||||
@ -173,9 +173,8 @@ virtualization system. It is still possible for the resulting instance to keep
|
||||
ephemeral storage, depending on the flavor selected. In this case, the root
|
||||
file system can be on the persistent volume, and its state is maintained, even
|
||||
if the instance is shut down. For more information about this type of
|
||||
configuration, see `Introduction to the Block Storage service
|
||||
<https://docs.openstack.org/cinder/latest/configuration/block-storage/block-storage-overview.html>`_
|
||||
in the OpenStack Configuration Reference.
|
||||
configuration, see :cinder-doc:`Introduction to the Block Storage service
|
||||
<configuration/block-storage/block-storage-overview.html>`.
|
||||
|
||||
.. note::
|
||||
|
||||
|
@ -376,11 +376,10 @@ Networking configuration
|
||||
------------------------
|
||||
|
||||
The Networking service in the Compute node is running
|
||||
``neutron-openvswitch-agent``, this manages dom0's OVS. You can refer
|
||||
Networking `openvswitch_agent.ini sample`__ for details,
|
||||
however there are several specific items to look out for.
|
||||
|
||||
__ https://docs.openstack.org/neutron/latest/configuration/samples/openvswitch-agent.html
|
||||
``neutron-openvswitch-agent``. This manages ``dom0``\'s OVS. You should refer
|
||||
to the :neutron-doc:`openvswitch_agent.ini sample
|
||||
<configuration/samples/openvswitch-agent.html>` for details, however there are
|
||||
several specific items to look out for.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
|
@ -14,9 +14,9 @@ compute nodes over ssh. For KVM you need hostnames to resolve properly and
|
||||
passwordless ssh access between your compute hosts. Direct access from one
|
||||
compute host to another is needed to copy the VM file across.
|
||||
|
||||
Cloud end users can find out how to resize a server by reading the `OpenStack
|
||||
End User Guide <https://docs.openstack.org/user-guide/
|
||||
cli_change_the_size_of_your_server.html>`_.
|
||||
Cloud end users can find out how to resize a server by reading the
|
||||
:python-openstackclient-doc:`OpenStack CLI Guide
|
||||
<cli/command-objects/server.html#server-resize>`
|
||||
|
||||
XenServer
|
||||
~~~~~~~~~
|
||||
|
@ -200,8 +200,8 @@ run:
|
||||
|
||||
$ openstack flavor set m1.large --property hw:mem_page_size=any
|
||||
|
||||
For more information about the syntax for ``hw:mem_page_size``, refer to the
|
||||
`Flavors`_ guide.
|
||||
For more information about the syntax for ``hw:mem_page_size``, refer to
|
||||
:doc:`flavors`.
|
||||
|
||||
Applications are frequently packaged as images. For applications that require
|
||||
the IO performance improvements that huge pages provides, configure image
|
||||
@ -235,5 +235,4 @@ guide.
|
||||
.. Links
|
||||
.. _`Linux THP guide`: https://www.kernel.org/doc/Documentation/vm/transhuge.txt
|
||||
.. _`Linux hugetlbfs guide`: https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt
|
||||
.. _`Flavors`: https://docs.openstack.org/admin-guide/compute-flavors.html
|
||||
.. _`Image metadata`: https://docs.openstack.org/image-guide/image-metadata.html
|
||||
|
@ -35,8 +35,8 @@ For more about the logging configuration syntax, including the ``handlers`` and
|
||||
on logging configuration files.
|
||||
|
||||
For an example of the ``logging.conf`` file with various defined handlers, see
|
||||
the `Example Configuration File for nova
|
||||
<https://docs.openstack.org/oslo.log/latest/admin/example_nova.html>`__.
|
||||
the :oslo.log-doc:`Example Configuration File for nova
|
||||
<admin/example_nova.html>`.
|
||||
|
||||
Syslog
|
||||
~~~~~~
|
||||
|
@ -21,9 +21,8 @@ might be restricted by the Identity service.
|
||||
variables for convenience), for the ability to administer the cloud from the
|
||||
command line.
|
||||
|
||||
To install python-openstackclient, follow the instructions in the `OpenStack
|
||||
User Guide
|
||||
<https://docs.openstack.org/user-guide/common/cli-install-openstack-command-line-clients.html>`_.
|
||||
For more information on ``python-openstackclient``, refer to the
|
||||
:python-openstackclient-doc:`documentation <>`.
|
||||
|
||||
#. Confirm the installation was successful:
|
||||
|
||||
@ -44,9 +43,9 @@ might be restricted by the Identity service.
|
||||
|
||||
$ openstack help SUBCOMMAND
|
||||
|
||||
For a complete list of ``openstack`` commands and parameters, see the
|
||||
`OpenStack Command-Line Reference
|
||||
<https://docs.openstack.org/cli-reference/openstack.html>`__.
|
||||
For a complete list of ``openstack`` commands and parameters, refer to the
|
||||
:python-openstackclient-doc:`OpenStack Command-Line Reference
|
||||
<cli/index.html>`.
|
||||
|
||||
#. Set the required parameters as environment variables to make running
|
||||
commands easier. For example, you can add ``--os-username`` as an
|
||||
|
@ -6,11 +6,11 @@ Depending on the setup of your cloud provider, they may give you an endpoint to
|
||||
use to manage volumes. You can use the ``openstack`` CLI to manage volumes.
|
||||
|
||||
For the purposes of the compute service, attaching, detaching and
|
||||
:doc:`creating a server from a volume <../user/launch-instance-from-volume>`
|
||||
are of primary interest.
|
||||
:doc:`creating a server from a volume </user/launch-instance-from-volume>` are
|
||||
of primary interest.
|
||||
|
||||
Refer to the `block storage service CLI guide on managing volumes
|
||||
<https://docs.openstack.org/cinder/latest/cli/cli-manage-volumes.html>`_.
|
||||
Refer to the :python-openstackclient-doc:`CLI documentation
|
||||
<cli/command-objects/volume.html>` for more information.
|
||||
|
||||
|
||||
Volume multi-attach
|
||||
@ -19,7 +19,8 @@ Volume multi-attach
|
||||
Nova `added support for multiattach volumes`_ in the 17.0.0 Queens release.
|
||||
|
||||
This document covers the nova-specific aspects of this feature. Refer
|
||||
to the `block storage admin guide`_ for more details about creating
|
||||
to the :cinder-doc:`block storage admin guide
|
||||
<admin/blockstorage-volume-multiattach.html>` for more details about creating
|
||||
multiattach-capable volumes.
|
||||
|
||||
Boot from volume and attaching a volume to a server that is not
|
||||
@ -33,11 +34,12 @@ Requirements
|
||||
~~~~~~~~~~~~
|
||||
|
||||
* The minimum required compute API microversion for attaching a
|
||||
multiattach-capable volume to more than one server is `2.60`_.
|
||||
multiattach-capable volume to more than one server is :ref:`2.60
|
||||
<api-microversion-queens>`.
|
||||
* Cinder 12.0.0 (Queens) or newer is required.
|
||||
* The ``nova-compute`` service must be running at least Queens release level
|
||||
code (17.0.0) and the hypervisor driver must support attaching block storage
|
||||
devices to more than one guest. Refer to the `feature support matrix`_ for
|
||||
devices to more than one guest. Refer to :doc:`/user/support-matrix` for
|
||||
details on which compute drivers support volume multiattach.
|
||||
* When using the libvirt compute driver, the following native package versions
|
||||
determine multiattach support:
|
||||
@ -72,9 +74,6 @@ volume back end. It purposefully does not use the Pike Ubuntu Cloud Archive
|
||||
package mirror so that it gets qemu<2.10.
|
||||
|
||||
.. _added support for multiattach volumes: https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/multi-attach-volume.html
|
||||
.. _block storage admin guide: https://docs.openstack.org/cinder/latest/admin/blockstorage-volume-multiattach.html
|
||||
.. _recorded overview and demo: https://www.youtube.com/watch?v=hZg6wqxdEHk
|
||||
.. _2.60: https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-queens
|
||||
.. _feature support matrix: https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_multiattach_volume
|
||||
.. _nova repository: http://git.openstack.org/cgit/openstack/nova/tree/playbooks/legacy/nova-multiattach/run.yaml
|
||||
.. _tempest repository: http://codesearch.openstack.org/?q=CONF.compute_feature_enabled.volume_multiattach&i=nope&files=&repos=tempest
|
||||
|
@ -13,8 +13,8 @@ configuration for your Compute instances.
|
||||
|
||||
You can choose to either install and configure ``nova-network`` or use the
|
||||
OpenStack Networking service (neutron). This section contains a brief overview
|
||||
of ``nova-network``. For more information about OpenStack Networking, see
|
||||
`Networking <https://docs.openstack.org/admin-guide/networking.html>`_.
|
||||
of ``nova-network``. For more information about OpenStack Networking, refer to
|
||||
:neutron-doc:`the documentation <>`.
|
||||
|
||||
Networking concepts
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
@ -417,9 +417,8 @@ Configure public (floating) IP addresses
|
||||
|
||||
This section describes how to configure floating IP addresses with
|
||||
``nova-network``. For information about doing this with OpenStack Networking,
|
||||
see `L3-routing-and-NAT
|
||||
<https://docs.openstack.org/neutron/latest/admin/archives/adv-features.html
|
||||
#l3-routing-and-nat>`_.
|
||||
refer to :neutron-doc:`L3-routing-and-NAT
|
||||
<admin/archives/adv-features.html#l3-routing-and-nat>`.
|
||||
|
||||
Private and public IP addresses
|
||||
-------------------------------
|
||||
@ -561,9 +560,9 @@ perform floating IP operations:
|
||||
# openstack floating ip delete CIDR
|
||||
|
||||
For more information about how administrators can associate floating IPs with
|
||||
instances, see `ip floating
|
||||
<https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/
|
||||
ip-floating.html>`__ in the python-openstackclient User Documentation.
|
||||
instances, see :python-openstackclient-doc:`ip floating
|
||||
<cli/command-objects/ip-floating.html>` in the *python-openstackclient* User
|
||||
Documentation.
|
||||
|
||||
Automatically add floating IPs
|
||||
------------------------------
|
||||
|
@ -18,7 +18,7 @@ assigned to only one guest and cannot be shared.
|
||||
.. note::
|
||||
|
||||
For information on attaching virtual SR-IOV devices to guests, refer to the
|
||||
`Networking Guide`_.
|
||||
:neutron-doc:`Networking Guide <admin/config-sriov>`.
|
||||
|
||||
To enable PCI passthrough, follow the steps below:
|
||||
|
||||
@ -40,7 +40,9 @@ To enable PCI passthrough, follow the steps below:
|
||||
Configure nova-scheduler (Controller)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Configure ``nova-scheduler`` as specified in `Configure nova-scheduler`_.
|
||||
#. Configure ``nova-scheduler`` as specified in :neutron-doc:`Configure
|
||||
nova-scheduler
|
||||
<admin/config-sriov.html#configure-nova-scheduler-controller`.
|
||||
|
||||
#. Restart the ``nova-scheduler`` service.
|
||||
|
||||
@ -82,7 +84,8 @@ Enable PCI passthrough (Compute)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Enable VT-d and IOMMU. For more information, refer to steps one and two in
|
||||
`Create Virtual Functions`_.
|
||||
:neutron-doc:`Create Virtual Functions
|
||||
<admin/config-sriov.html#create-virtual-functions-compute`.
|
||||
|
||||
For Hyper-V compute nodes, the requirements are as follows:
|
||||
|
||||
@ -100,8 +103,10 @@ devices, run the following Powershell commands:
|
||||
|
||||
If the compute node passes all the requirements, the desired assignable PCI
|
||||
devices to be disabled and unmounted from the host, in order to be assignable
|
||||
by Hyper-V. The following can be read for more details: `Hyper-V PCI passthrough`_.
|
||||
by Hyper-V. The following can be read for more details: `Hyper-V PCI
|
||||
passthrough`__.
|
||||
|
||||
.. __: https://blogs.technet.microsoft.com/heyscriptingguy/2016/07/14/passing-through-devices-to-hyper-v-vms-by-using-discrete-device-assignment/
|
||||
|
||||
Configure PCI devices (Compute)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -157,9 +162,3 @@ available with the specified ``vendor_id`` and ``product_id`` that matches the
|
||||
.. code-block:: console
|
||||
|
||||
# openstack server create --flavor m1.large --image cirros-0.3.5-x86_64-uec --wait test-pci
|
||||
|
||||
.. Links
|
||||
.. _`Create Virtual Functions`: https://docs.openstack.org/neutron/latest/admin/config-sriov.html#create-virtual-functions-compute
|
||||
.. _`Configure nova-scheduler`: https://docs.openstack.org/neutron/latest/admin/config-sriov.html#configure-nova-scheduler-controller
|
||||
.. _`Networking Guide`: https://docs.openstack.org/neutron/latest/admin/config-sriov.html
|
||||
.. _`Hyper-V PCI passthrough`: https://blogs.technet.microsoft.com/heyscriptingguy/2016/07/14/passing-through-devices-to-hyper-v-vms-by-using-discrete-device-assignment/
|
||||
|
@ -47,8 +47,7 @@ To use the memcache driver, you must install memcached. You might already have
|
||||
it installed, as the same driver is also used for the OpenStack Object Storage
|
||||
and OpenStack dashboard. To install memcached, see the *Environment ->
|
||||
Memcached* section in the `Installation Tutorials and Guides
|
||||
<https://docs.openstack.org/project-install-guide/ocata>`_ depending on your
|
||||
distribution.
|
||||
<https://docs.openstack.org/install-guide>`_ depending on your distribution.
|
||||
|
||||
These values in the ``/etc/nova/nova.conf`` file are required on every node for
|
||||
the memcache driver:
|
||||
|
@ -66,9 +66,7 @@ Configure a flavor to request one virtual GPU:
|
||||
The enabled vGPU types on the compute hosts are not exposed to API users.
|
||||
Flavors configured for vGPU support can be tied to host aggregates as a means
|
||||
to properly schedule those flavors onto the compute hosts that support them.
|
||||
See the `host aggregates`_ guide for more information.
|
||||
|
||||
.. _host aggregates: https://docs.openstack.org/nova/latest/user/aggregates.html
|
||||
See the :doc:`/user/aggregates` for more information.
|
||||
|
||||
Create instances with virtual GPU devices
|
||||
-----------------------------------------
|
||||
|
@ -41,8 +41,8 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* `Using WSGI with Nova <https://docs.openstack.org/nova/latest/wsgi.html>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
* :nova-doc:`Using WSGI with Nova <wsgi.html>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -41,8 +41,8 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* `Using WSGI with Nova <https://docs.openstack.org/nova/latest/user/wsgi.html>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
* :nova-doc:`Using WSGI with Nova <user/wsgi.html>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -41,8 +41,8 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* `Using WSGI with Nova <https://docs.openstack.org/nova/latest/user/wsgi.html>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
* :nova-doc:`Using WSGI with Nova <user/wsgi.html>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -46,7 +46,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -42,7 +42,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -37,7 +37,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -41,7 +41,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -45,7 +45,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -48,7 +48,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -279,7 +279,7 @@ Nova Cells v2
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -45,7 +45,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -41,7 +41,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -57,7 +57,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -41,7 +41,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -41,7 +41,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -41,7 +41,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -93,7 +93,7 @@ Upgrade
|
||||
make a successful request to the endpoint. The command also checks to
|
||||
see that there are compute node resource providers checking in with the
|
||||
Placement service. More information on the Placement service can be found
|
||||
at: `<https://docs.openstack.org/nova/latest/user/placement.html>`_
|
||||
at :nova-doc:`user/placement.html>`.
|
||||
|
||||
**16.0.0 (Pike)**
|
||||
|
||||
@ -117,7 +117,7 @@ Upgrade
|
||||
See Also
|
||||
========
|
||||
|
||||
* OpenStack Nova Docs: `<https://docs.openstack.org/nova/latest/>`_
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -41,7 +41,7 @@ Files
|
||||
See Also
|
||||
========
|
||||
|
||||
* `OpenStack Nova <https://docs.openstack.org/nova/latest/>`__
|
||||
* :nova-doc:`OpenStack Nova <>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
@ -171,6 +171,27 @@ latex_documents = [
|
||||
u'OpenStack Foundation', 'manual'),
|
||||
]
|
||||
|
||||
# -- Options for openstackdocstheme -------------------------------------------
|
||||
|
||||
# keep this ordered to keep mriedem happy
|
||||
openstack_projects = [
|
||||
'ceilometer',
|
||||
'cinder',
|
||||
'glance',
|
||||
'horizon',
|
||||
'ironic',
|
||||
'keystone',
|
||||
'neutron',
|
||||
'nova',
|
||||
'oslo.log',
|
||||
'oslo.messaging',
|
||||
'oslo.i18n',
|
||||
'oslo.versionedobjects',
|
||||
'python-novaclient',
|
||||
'python-openstackclient',
|
||||
'reno',
|
||||
'watcher',
|
||||
]
|
||||
# -- Custom extensions --------------------------------------------------------
|
||||
|
||||
|
||||
|
@ -328,7 +328,7 @@ How to do great nova-spec reviews?
|
||||
|
||||
https://specs.openstack.org/openstack/nova-specs/specs/rocky/template.html
|
||||
|
||||
https://docs.openstack.org/nova/latest/contributor/blueprints.html#specs
|
||||
:doc:`/contributor/blueprints`.
|
||||
|
||||
Spec reviews are always a step ahead of the normal code reviews. Follow
|
||||
the above links for some great information on specs/reviews.
|
||||
|
@ -356,8 +356,8 @@ necessary to add changes to other places which describe your change:
|
||||
* Add a verbose description to
|
||||
``nova/api/openstack/compute/rest_api_version_history.rst``.
|
||||
|
||||
* Add a `release note`_ with a ``features`` section announcing the new or
|
||||
changed feature and the microversion.
|
||||
* Add a :doc:`release note </contributor/releasenotes>` with a ``features``
|
||||
section announcing the new or changed feature and the microversion.
|
||||
|
||||
* Update the expected versions in affected tests, for example in
|
||||
``nova/tests/unit/api/openstack/compute/test_versions.py``.
|
||||
@ -375,7 +375,6 @@ necessary to add changes to other places which describe your change:
|
||||
* Update the `API Reference`_ documentation as appropriate. The source is
|
||||
located under `api-ref/source/`.
|
||||
|
||||
.. _release note: https://docs.openstack.org/nova/latest/contributor/releasenotes.html
|
||||
.. _API Reference: https://developer.openstack.org/api-ref/compute/
|
||||
|
||||
Allocating a microversion
|
||||
|
@ -40,10 +40,11 @@ increasing the number of WSGI application instances and scaling the RDBMS using
|
||||
traditional database scaling techniques.
|
||||
|
||||
For sake of consistency and because there was initially intent to make the
|
||||
entities in the placement service available over RPC, `versioned objects`_ are
|
||||
used to provide the interface between the HTTP application layer and the
|
||||
SQLAlchemy-driven persistence layer. Even without RPC, these objects provide
|
||||
useful structuring and separation of the code.
|
||||
entities in the placement service available over RPC,
|
||||
:oslo.versionedobjects-doc:`versioned objects <>` are used to provide the
|
||||
interface between the HTTP application layer and the SQLAlchemy-driven
|
||||
persistence layer. Even without RPC, these objects provide useful structuring
|
||||
and separation of the code.
|
||||
|
||||
Though the placement service doesn't aspire to be a `microservice` it does
|
||||
aspire to continue to be small and minimally complex. This means a relatively
|
||||
@ -145,8 +146,8 @@ there are a few bits of required housekeeping that must be done in the code:
|
||||
microversion and give a very brief summary of the added feature.
|
||||
* Update ``nova/api/openstack/placement/rest_api_version_history.rst``
|
||||
to add a more detailed section describing the new microversion.
|
||||
* Add a `release note`_ with a ``features`` section announcing the new or
|
||||
changed feature and the microversion.
|
||||
* Add a :reno-doc:`release note <>` with a ``features`` section announcing the
|
||||
new or changed feature and the microversion.
|
||||
* If the ``version_handler`` decorator (see below) has been used,
|
||||
increment ``TOTAL_VERSIONED_METHODS`` in
|
||||
``nova/tests/unit/api/openstack/placement/test_microversion.py``.
|
||||
@ -413,13 +414,11 @@ When creating new code for the placement service, please be aware of the plan
|
||||
for an eventual extraction and avoid creating unnecessary interdependencies.
|
||||
|
||||
.. _WSGI: https://www.python.org/dev/peps/pep-3333/
|
||||
.. _versioned objects: http://docs.openstack.org/developer/oslo.versionedobjects/
|
||||
.. _wsgify: http://docs.webob.org/en/latest/api/dec.html
|
||||
.. _WebOb: http://docs.webob.org/en/latest/
|
||||
.. _Request: http://docs.webob.org/en/latest/reference.html#request
|
||||
.. _Response: http://docs.webob.org/en/latest/#response
|
||||
.. _microversions: http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
|
||||
.. _release note: https://docs.openstack.org/reno/latest/user/usage.html
|
||||
.. _gabbi: https://gabbi.readthedocs.io/
|
||||
.. _telemetry: http://specs.openstack.org/openstack/telemetry-specs/specs/kilo/declarative-http-tests.html
|
||||
.. _wsgi-intercept: http://wsgi-intercept.readthedocs.io/
|
||||
|
@ -108,7 +108,8 @@ Metrics Gathering
|
||||
Nova currently has a monitor plugin to gather CPU metrics on compute nodes.
|
||||
This feeds into the MetricsFilter and MetricsWeigher in the scheduler. The
|
||||
CPU metrics monitor is only implemented for the libvirt compute driver.
|
||||
External projects like `Ceilometer`_ and `Watcher`_ consume these metrics.
|
||||
External projects like :ceilometer-doc:`Ceilometer <>` and
|
||||
:watcher-doc:`Watcher <>` consume these metrics.
|
||||
|
||||
Over time people have tried to add new monitor plugins for things like memory
|
||||
bandwidth. There have also been attempts to expose these monitors over CLI,
|
||||
@ -127,6 +128,4 @@ replacement, the deprecation is open-ended, but serves as a signal that new
|
||||
deployments should not rely on the metrics that Nova gathers and should instead
|
||||
focus their efforts on alternative solutions for placement.
|
||||
|
||||
.. _Ceilometer: https://docs.openstack.org/ceilometer/latest/
|
||||
.. _Watcher: https://docs.openstack.org/watcher/latest/
|
||||
.. _Newton midcycle: http://lists.openstack.org/pipermail/openstack-dev/2016-August/100600.html
|
||||
|
@ -223,9 +223,7 @@ when you create the bug report).
|
||||
When do I need a blueprint vs a spec?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For more details see:
|
||||
|
||||
- https://docs.openstack.org/nova/latest/contributor/blueprints.html
|
||||
For more details refer to :doc:`/contributor/blueprints`.
|
||||
|
||||
To understand this question, we need to understand why blueprints and
|
||||
specs are useful.
|
||||
@ -426,8 +424,7 @@ Interoperable API, supporting a vibrant ecosystem
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
An interoperable API that gives users on-demand access to compute
|
||||
resources is at the heart of Nova's mission:
|
||||
https://docs.openstack.org/nova/latest/contributor/project-scope.html#mission
|
||||
resources is at the heart of :ref:`nova's mission <nova-mission>`.
|
||||
|
||||
Nova has a vibrant ecosystem of tools built on top of the current Nova
|
||||
API. All features should be designed to work with all technology
|
||||
@ -910,9 +907,8 @@ this technique during M.
|
||||
Feature Classification
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This is a look at moving forward this effort:
|
||||
|
||||
- https://docs.openstack.org/nova/latest/user/support-matrix.html
|
||||
This is a look at moving forward the :doc:`support matrix effort
|
||||
</user/support-matrix>`.
|
||||
|
||||
The things we need to cover:
|
||||
|
||||
|
@ -22,8 +22,10 @@ should and should not be doing, and why.
|
||||
Please treat this as a discussion of interesting, and hopefully useful,
|
||||
examples. It is not intended to be an exhaustive policy statement.
|
||||
|
||||
.. _nova-mission:
|
||||
|
||||
Mission
|
||||
--------
|
||||
-------
|
||||
|
||||
Our mission statement starts with:
|
||||
|
||||
|
@ -6,13 +6,12 @@ Release Notes
|
||||
What is reno ?
|
||||
--------------
|
||||
|
||||
Nova uses `reno <http://docs.openstack.org/developer/reno/usage.html>`_ for
|
||||
providing release notes in-tree. That means that a patch can include a *reno
|
||||
file* or a series can have a follow-on change containing that file explaining
|
||||
what the impact is.
|
||||
Nova uses :reno-doc:`reno <>` for providing release notes in-tree. That means
|
||||
that a patch can include a *reno file* or a series can have a follow-on change
|
||||
containing that file explaining what the impact is.
|
||||
|
||||
A *reno file* is a YAML file written in the releasenotes/notes tree which is
|
||||
generated using the reno tool this way:
|
||||
A *reno file* is a YAML file written in the ``releasenotes/notes`` tree which
|
||||
is generated using the *reno* tool this way:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -21,8 +20,7 @@ generated using the reno tool this way:
|
||||
where usually ``<name-your-file>`` can be ``bp-<blueprint_name>`` for a
|
||||
blueprint or ``bug-XXXXXX`` for a bugfix.
|
||||
|
||||
Refer to the `reno documentation <http://docs.openstack.org/developer/reno/usage.html#editing-a-release-note>`_
|
||||
for the full list of sections.
|
||||
Refer to the :reno-doc:`reno documentation <user/index.html>` for more information.
|
||||
|
||||
|
||||
When a release note is needed
|
||||
@ -48,8 +46,10 @@ need to provide a release note :-)
|
||||
* If the patch has an `APIImpact <http://docs.openstack.org/infra/manual/developers.html#peer-review>`_ tag
|
||||
* For nova-manage and python-novaclient changes, if it adds or changes a
|
||||
new command, including adding new options to existing commands
|
||||
* not all blueprints in general, just the ones impacting a `contractual API <http://docs.openstack.org/developer/nova/policies.html#public-contractual-apis>`_
|
||||
* a new virt driver is provided or an existing driver impacts the `HypervisorSupportMatrix <http://docs.openstack.org/developer/nova/support-matrix.html>`_
|
||||
* not all blueprints in general, just the ones impacting a
|
||||
:doc:`/contributor/policies`
|
||||
* a new virt driver is provided or an existing driver impacts the
|
||||
:doc:`HypervisorSupportMatrix </user/support-matrix>`
|
||||
|
||||
* ``critical``
|
||||
* Bugfixes categorized as Critical in Launchpad *impacting users*
|
||||
|
@ -30,13 +30,12 @@ servers to provide that service.
|
||||
|
||||
It requires the following additional OpenStack services for basic function:
|
||||
|
||||
* `Keystone <https://docs.openstack.org/keystone/latest/>`__: This provides
|
||||
identity and authentication for all OpenStack services.
|
||||
* `Glance <https://docs.openstack.org/glance/latest/>`__: This provides the
|
||||
compute image repository. All compute instances launch from glance images.
|
||||
* `Neutron <https://docs.openstack.org/neutron/latest/>`__: This is
|
||||
responsible for provisioning the virtual or physical networks that compute
|
||||
instances connect to on boot.
|
||||
* :keystone-doc:`Keystone <>`: This provides identity and authentication for
|
||||
all OpenStack services.
|
||||
* :glance-doc:`Glance <>`: This provides the compute image repository. All
|
||||
compute instances launch from glance images.
|
||||
* :neutron-doc:`Neutron <>`: This is responsible for provisioning the virtual
|
||||
or physical networks that compute instances connect to on boot.
|
||||
|
||||
It can also integrate with other services to include: persistent block
|
||||
storage, encrypted disks, and baremetal compute instances.
|
||||
@ -50,19 +49,15 @@ either tools or the API directly.
|
||||
Tools for using Nova
|
||||
--------------------
|
||||
|
||||
* `Horizon
|
||||
<https://docs.openstack.org/horizon/latest/user/launch-instances.html>`_: The
|
||||
official web ui for the OpenStack Project.
|
||||
* `OpenStack Client
|
||||
<https://docs.openstack.org/python-openstackclient/latest/>`_: The official
|
||||
CLI for OpenStack Projects. You should use this as your CLI for most things,
|
||||
it includes not just nova commands but also commands for most of the projects
|
||||
in OpenStack.
|
||||
* `Nova Client
|
||||
<https://docs.openstack.org/python-novaclient/latest/user/shell.html>`_: For
|
||||
some very advanced features (or administrative commands) of nova you may need
|
||||
to use nova client. It is still supported, but the ``openstack`` cli is
|
||||
recommended.
|
||||
* :horizon-doc:`Horizon <user/launch-instances.html>`: The official web UI for
|
||||
the OpenStack Project.
|
||||
* :python-openstackclient-doc:`OpenStack Client <>`: The official CLI for
|
||||
OpenStack Projects. You should use this as your CLI for most things, it
|
||||
includes not just nova commands but also commands for most of the projects in
|
||||
OpenStack.
|
||||
* :python-novaclient-doc:`Nova Client <user/shell.html>`: For some very
|
||||
advanced features (or administrative commands) of nova you may need to use
|
||||
nova client. It is still supported, but the ``openstack`` cli is recommended.
|
||||
|
||||
Writing to the API
|
||||
------------------
|
||||
@ -117,11 +112,9 @@ Installation
|
||||
.. TODO(sdague): links to all the rest of the install guide pieces.
|
||||
|
||||
The detailed install guide for nova. A functioning nova will also require
|
||||
having installed `keystone
|
||||
<https://docs.openstack.org/keystone/latest/install/>`__, `glance
|
||||
<https://docs.openstack.org/glance/latest/install/>`__, and `neutron
|
||||
<https://docs.openstack.org/neutron/latest/install/>`__. Please ensure that you
|
||||
follow their install guides first.
|
||||
having installed :keystone-doc:`keystone <install/>`, :glance-doc:`glance
|
||||
<install/>`, and :neutron-doc:`neutron <install/>`. Ensure that you follow
|
||||
their install guides first.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
@ -122,10 +122,9 @@ Install and configure components
|
||||
firewall service by using the
|
||||
``nova.virt.firewall.NoopFirewallDriver`` firewall driver.
|
||||
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. See the
|
||||
`Networking service install guide`__ for more details.
|
||||
|
||||
.. __: https://docs.openstack.org/neutron/latest/install/compute-install-obs.html#configure-the-compute-service-to-use-the-networking-service
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. Refer to
|
||||
the :neutron-doc:`Networking service install guide
|
||||
<install/compute-install-obs.html>` for more details.
|
||||
|
||||
* In the ``[vnc]`` section, enable and configure remote console access:
|
||||
|
||||
|
@ -114,10 +114,10 @@ Install and configure components
|
||||
service by using the ``nova.virt.firewall.NoopFirewallDriver`` firewall
|
||||
driver.
|
||||
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. See the
|
||||
`Networking service install guide`__ for more details.
|
||||
|
||||
.. __: https://docs.openstack.org/neutron/latest/install/compute-install-rdo.html#configure-the-compute-service-to-use-the-networking-service
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. Refer to
|
||||
the :neutron-doc:`Networking service install guide
|
||||
<install/compute-install-rdo.html#configure-the-compute-service-to-use-the-networking-service>`
|
||||
for more details.
|
||||
|
||||
* In the ``[vnc]`` section, enable and configure remote console access:
|
||||
|
||||
|
@ -104,10 +104,10 @@ Install and configure components
|
||||
service by using the ``nova.virt.firewall.NoopFirewallDriver`` firewall
|
||||
driver.
|
||||
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. See the
|
||||
`Networking service install guide`__ for more details.
|
||||
|
||||
.. __: https://docs.openstack.org/neutron/latest/install/compute-install-ubuntu.html#configure-the-compute-service-to-use-the-networking-service
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. Refer to
|
||||
the :neutron-doc:`Networking service install guide
|
||||
<install/compute-install-ubuntu.html#configure-the-compute-service-to-use-the-networking-service>`
|
||||
for more details.
|
||||
|
||||
* In the ``[vnc]`` section, enable and configure remote console access:
|
||||
|
||||
|
@ -378,10 +378,10 @@ Install and configure components
|
||||
Compute firewall driver by using the
|
||||
``nova.virt.firewall.NoopFirewallDriver`` firewall driver.
|
||||
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. See the
|
||||
`Networking service install guide`__ for more details.
|
||||
|
||||
.. __: https://docs.openstack.org/neutron/latest/install/controller-install-obs.html#configure-the-compute-service-to-use-the-networking-service
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. Refer to
|
||||
the :neutron-doc:`Networking service install guide
|
||||
<install/controller-install-obs.html#configure-the-compute-service-to-use-the-networking-service>`
|
||||
for more details.
|
||||
|
||||
* In the ``[vnc]`` section, configure the VNC proxy to use the management
|
||||
interface IP address of the controller node:
|
||||
|
@ -369,10 +369,9 @@ Install and configure components
|
||||
Compute firewall driver by using the
|
||||
``nova.virt.firewall.NoopFirewallDriver`` firewall driver.
|
||||
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. See the
|
||||
`Networking service install guide`__ for more details.
|
||||
|
||||
.. __: https://docs.openstack.org/neutron/latest/install/controller-install-rdo.html#configure-the-compute-service-to-use-the-networking-service
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. Refer to
|
||||
the :neutron-doc:`Networking service install guide
|
||||
<install/compute-install-rdo.html>` for more details.
|
||||
|
||||
* In the ``[vnc]`` section, configure the VNC proxy to use the management
|
||||
interface IP address of the controller node:
|
||||
|
@ -359,10 +359,10 @@ Install and configure components
|
||||
Compute firewall driver by using the
|
||||
``nova.virt.firewall.NoopFirewallDriver`` firewall driver.
|
||||
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. See the
|
||||
`Networking service install guide`__ for more details.
|
||||
|
||||
.. __: https://docs.openstack.org/neutron/latest/install/controller-install-ubuntu.html#configure-the-compute-service-to-use-the-networking-service
|
||||
* Configure the ``[neutron]`` section of **/etc/nova/nova.conf**. Refer to
|
||||
the :neutron-doc:`Networking service install guide
|
||||
<install/controller-install-ubuntu.html#configure-the-compute-service-to-use-the-networking-service>`
|
||||
for more information.
|
||||
|
||||
* In the ``[vnc]`` section, configure the VNC proxy to use the management
|
||||
interface IP address of the controller node:
|
||||
|
@ -1,8 +1,7 @@
|
||||
Internationalization
|
||||
====================
|
||||
|
||||
Nova uses the `oslo.i18n library
|
||||
<http://docs.openstack.org/developer/oslo.i18n/index.html>`_ to support
|
||||
Nova uses the :oslo.i18n-doc:`oslo.i18n library <>` to support
|
||||
internationalization. The oslo.i18n library is built on top of `gettext
|
||||
<http://docs.python.org/library/gettext.html>`_ and provides functions that are
|
||||
used to enable user-facing strings such as log messages to appear in the
|
||||
|
@ -13,12 +13,13 @@
|
||||
|
||||
Notifications in Nova
|
||||
=====================
|
||||
|
||||
Similarly to other OpenStack services Nova emits notifications to the message
|
||||
bus with the Notifier class provided by oslo.messaging [1]_. From the
|
||||
notification consumer point of view a notification consists of two parts: an
|
||||
envelope with a fixed structure defined by oslo.messaging and a payload defined
|
||||
by the service emitting the notification. The envelope format is the
|
||||
following::
|
||||
bus with the Notifier class provided by :oslo.messaging-doc:`oslo.messaging
|
||||
<reference/notifier.html>`. From the notification consumer point of view a
|
||||
notification consists of two parts: an envelope with a fixed structure defined
|
||||
by oslo.messaging and a payload defined by the service emitting the
|
||||
notification. The envelope format is the following::
|
||||
|
||||
{
|
||||
"priority": <string, selected from a predefined list by the sender>,
|
||||
@ -62,7 +63,7 @@ The versioned notification concept is created to fix the shortcomings of the
|
||||
unversioned notifications. The envelope structure of the emitted notification
|
||||
is the same as in the unversioned notification case as it is provided by
|
||||
oslo.messaging. However the payload is not a free form dictionary but a
|
||||
serialized oslo versionedobject [2]_.
|
||||
serialized :oslo.versionedobjects-doc:`oslo versionedobjects object <>`.
|
||||
|
||||
.. _service.update:
|
||||
|
||||
@ -300,9 +301,9 @@ notification should be created with care to avoid future needs of adding extra
|
||||
level of inheritance that changes the name of the leaf class as that name is
|
||||
present in the payload class. If this cannot be avoided and the only change is
|
||||
the renaming then the version of the new payload shall be the same as the old
|
||||
payload was before the rename. See [3]_ as an example. If the renaming
|
||||
payload was before the rename. See [1]_ as an example. If the renaming
|
||||
involves any other changes on the payload (e.g. adding new fields) then the
|
||||
version of the new payload shall be higher than the old payload was. See [4]_
|
||||
version of the new payload shall be higher than the old payload was. See [2]_
|
||||
as an example.
|
||||
|
||||
What should be in the notification payload
|
||||
@ -344,9 +345,5 @@ Existing versioned notifications
|
||||
|
||||
.. versioned_notifications::
|
||||
|
||||
|
||||
|
||||
.. [1] http://docs.openstack.org/developer/oslo.messaging/notifier.html
|
||||
.. [2] http://docs.openstack.org/developer/oslo.versionedobjects
|
||||
.. [3] https://review.openstack.org/#/c/463001/
|
||||
.. [4] https://review.openstack.org/#/c/453077/
|
||||
.. [1] https://review.openstack.org/#/c/463001/
|
||||
.. [2] https://review.openstack.org/#/c/453077/
|
||||
|
@ -285,10 +285,11 @@ Notifications
|
||||
|
||||
With a multi-cell environment with multiple message queues, it is
|
||||
likely that operators will want to configure a separate connection to
|
||||
a unified queue for notifications. This can be done in the
|
||||
configuration file of all nodes. See the `oslo.messaging configuration
|
||||
<https://docs.openstack.org/oslo.messaging/latest/configuration/opts.html#oslo_messaging_notifications.transport_url>`_
|
||||
documentation for more details.
|
||||
a unified queue for notifications. This can be done in the configuration file
|
||||
of all nodes. Refer to the :oslo.messaging-doc:`oslo.messaging configuration
|
||||
documentation
|
||||
<configuration/opts.html#oslo_messaging_notifications.transport_url>` for more
|
||||
details.
|
||||
|
||||
Neutron Metadata API proxy
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -63,12 +63,10 @@ RXTX Factor
|
||||
|
||||
.. note::
|
||||
|
||||
This property only applies if using the `xen` compute driver with the
|
||||
`nova-network` network driver. It will likely be deprecated in a future
|
||||
release. `neutron` users should refer to the `neutron QoS
|
||||
documentation`__.
|
||||
|
||||
__ https://docs.openstack.org/neutron/latest/admin/config-qos.html
|
||||
This property only applies if using the ``xen`` compute driver with the
|
||||
``nova-network`` network driver. It will likely be deprecated in a future
|
||||
release. ``neutron`` users should refer to the :neutron-doc:`neutron QoS
|
||||
documentation <admin/config-qos.html>`
|
||||
|
||||
Is Public
|
||||
Boolean value that defines whether the flavor is available to all users or
|
||||
|
@ -35,10 +35,10 @@ To complete these tasks, use these parameters on the
|
||||
|
||||
.. note::
|
||||
|
||||
To attach a volume to a running instance, see
|
||||
`Attach a volume to an instance`_.
|
||||
To attach a volume to a running instance, refer to the
|
||||
:cinder-doc:`Cinder documentation
|
||||
<cli/cli-manage-volumes.html#attach-a-volume-to-an-instance>`.
|
||||
|
||||
.. _Attach a volume to an instance: https://docs.openstack.org/cinder/latest/cli/cli-manage-volumes.html#attach-a-volume-to-an-instance
|
||||
.. _Boot_instance_from_image_and_attach_non-bootable_volume:
|
||||
|
||||
Boot instance from image and attach non-bootable volume
|
||||
@ -293,8 +293,8 @@ the volume to boot an instance.
|
||||
|
||||
|
||||
This requires an encrypted volume type, which must be created ahead of
|
||||
time by an admin. See
|
||||
`Create an encrypted volume type <https://docs.openstack.org/horizon/latest/admin/manage-volumes.html#create-an-encrypted-volume-type>`_
|
||||
time by an admin. Refer to
|
||||
:horizon-doc:`admin/manage-volumes.html#create-an-encrypted-volume-type`.
|
||||
in the OpenStack Horizon Administration Guide.
|
||||
|
||||
#. Create a VM from previously created bootable volume. The volume is not
|
||||
|
@ -758,6 +758,8 @@ Added pagination support for migrations, there are four changes:
|
||||
* The query parameter schema of the ``GET /os-migrations`` API no longer
|
||||
allows additional properties.
|
||||
|
||||
.. _api-microversion-queens:
|
||||
|
||||
2.60 (Maximum in Queens)
|
||||
------------------------
|
||||
|
||||
|
@ -88,3 +88,9 @@ latex_documents = [
|
||||
('index', 'Placement.tex', u'OpenStack Placement API Documentation',
|
||||
u'OpenStack Foundation', 'manual'),
|
||||
]
|
||||
|
||||
# -- Options for openstackdocstheme -------------------------------------------
|
||||
|
||||
openstack_projects = [
|
||||
'nova',
|
||||
]
|
||||
|
@ -5,8 +5,8 @@
|
||||
===============
|
||||
|
||||
This is a reference for the OpenStack Placement API. To learn more about
|
||||
OpenStack Placement API concepts, please refer to the
|
||||
`Placement Introduction <https://docs.openstack.org/nova/latest/user/placement.html>`_.
|
||||
OpenStack Placement API concepts, please refer to the :nova-doc:`Placement
|
||||
Introduction <user/placement.html>`.
|
||||
|
||||
The Placement API uses JSON for data exchange. As such, the ``Content-Type``
|
||||
header for APIs sending data payloads in the request body (i.e. ``PUT`` and
|
||||
|
Loading…
Reference in New Issue
Block a user