Merge "doc: Start using openstackdoctheme's extlink extension"
This commit is contained in:
		| @@ -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 | ||||
|   | ||||
		Reference in New Issue
	
	Block a user
	 Zuul
					Zuul