Merge "[doc]Remove eventlet based API endpoints"
This commit is contained in:
Zuul
Gerrit Code Review
commit
2fa61a0ad2
@ -34,14 +34,14 @@ This means a multi-cell deployment will not be radically different from a
|
||||
|
||||
Consider such a deployment. It will consists of the following components:
|
||||
|
||||
- The :program:`nova-api` service which provides the external REST API to
|
||||
- The :program:`nova-api-wsgi` service which provides the external REST API to
|
||||
users.
|
||||
|
||||
- The :program:`nova-scheduler` and ``placement`` services which are
|
||||
responsible for tracking resources and deciding which compute node instances
|
||||
should be on.
|
||||
|
||||
- An "API database" that is used primarily by :program:`nova-api` and
|
||||
- An "API database" that is used primarily by :program:`nova-api-wsgi` and
|
||||
:program:`nova-scheduler` (called *API-level services* below) to track
|
||||
location information about instances, as well as a temporary location for
|
||||
instances being built but not yet scheduled.
|
||||
@ -269,7 +269,7 @@ API database
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The API database is the database used for API-level services, such as
|
||||
:program:`nova-api` and, in a multi-cell deployment, the superconductor.
|
||||
:program:`nova-api-wsgi` and, in a multi-cell deployment, the superconductor.
|
||||
The models and migrations related to this database can be found in
|
||||
``nova.db.api``, and the database can be managed using the
|
||||
:program:`nova-manage api_db` commands.
|
||||
@ -800,7 +800,7 @@ If you have networks that span cells, you might need to run Nova metadata API
|
||||
globally. When running globally, it should be configured as an API-level
|
||||
service with access to the :oslo.config:option:`api_database.connection`
|
||||
information. The nova metadata API service **must not** be run as a standalone
|
||||
service, using the :program:`nova-api-metadata` service, in this case.
|
||||
service, using the :program:`nova-metadata-wsgi` service, in this case.
|
||||
|
||||
.. rubric:: Local per cell
|
||||
|
||||
@ -810,9 +810,9 @@ cell boundaries, then you can run Nova metadata API service per cell. If you
|
||||
choose to run it per cell, you should also configure each
|
||||
:neutron-doc:`neutron-metadata-agent
|
||||
<configuration/metadata-agent.html?#DEFAULT.nova_metadata_host>` service to
|
||||
point to the corresponding :program:`nova-api-metadata`. The nova metadata API
|
||||
point to the corresponding :program:`nova-metadata-wsgi`. The nova metadata API
|
||||
service **must** be run as a standalone service, using the
|
||||
:program:`nova-api-metadata` service, in this case.
|
||||
:program:`nova-metadata-wsgi` service, in this case.
|
||||
|
||||
Console proxies
|
||||
~~~~~~~~~~~~~~~
|
||||
@ -1024,7 +1024,7 @@ FAQs
|
||||
using the ``nova-manage cell_v2 update_cell`` command but the API is still
|
||||
trying to use the old settings.
|
||||
|
||||
The cell mappings are cached in the :program:`nova-api` service worker so you
|
||||
The cell mappings are cached in the :program:`nova-api-wsgi` service worker so you
|
||||
will need to restart the worker process to rebuild the cache. Note that there
|
||||
is another global cache tied to request contexts, which is used in the
|
||||
nova-conductor and nova-scheduler services, so you might need to do the same
|
||||
|
||||
@ -28,15 +28,11 @@ responsibilities of services and drivers are:
|
||||
|
||||
.. rubric:: Services
|
||||
|
||||
:doc:`nova-api-metadata </cli/nova-api-metadata>`
|
||||
A server daemon that serves the Nova Metadata API.
|
||||
:doc:`nova-metadata-wsgi </user/wsgi>`
|
||||
A WSGI application that serves the Nova Metadata API.
|
||||
|
||||
:doc:`nova-api-os-compute </cli/nova-api-os-compute>`
|
||||
A server daemon that serves the Nova OpenStack Compute API.
|
||||
|
||||
:doc:`nova-api </cli/nova-api>`
|
||||
A server daemon that serves the metadata and compute APIs in separate
|
||||
greenthreads.
|
||||
:doc:`nova-api-wsgi </user/wsgi>`
|
||||
A WSGI application that serves the Nova OpenStack Compute API.
|
||||
|
||||
:doc:`nova-compute </cli/nova-compute>`
|
||||
Manages virtual machines. Loads a Service object, and exposes the public
|
||||
|
||||
@ -14,10 +14,9 @@ metadata service supports two sets of APIs - an OpenStack metadata API and an
|
||||
EC2-compatible API - and also exposes vendordata and user data. Both the
|
||||
OpenStack metadata and EC2-compatible APIs are versioned by date.
|
||||
|
||||
The metadata service can be run globally, as part of the :program:`nova-api`
|
||||
application, or on a per-cell basis, as part of the standalone
|
||||
:program:`nova-api-metadata` application. A detailed comparison is provided in
|
||||
the :ref:`cells V2 guide <cells-v2-layout-metadata-api>`.
|
||||
The metadata service can be run globally, or on a per-cell basis. A detailed
|
||||
comparison is provided in the
|
||||
:ref:`cells V2 guide <cells-v2-layout-metadata-api>`.
|
||||
|
||||
.. versionchanged:: 19.0.0
|
||||
|
||||
|
||||
@ -291,7 +291,7 @@ Refer to :oslo.config:option:`pci.alias` for syntax information.
|
||||
Refer to :ref:`Affinity <pci-numa-affinity-policy>` for ``numa_policy``
|
||||
information.
|
||||
|
||||
Once configured, restart the :program:`nova-api` service.
|
||||
Once configured, restart the :program:`nova-api-wsgi` service.
|
||||
|
||||
|
||||
Configuring a flavor or image
|
||||
|
||||
@ -52,8 +52,8 @@ following components:
|
||||
|
||||
- One or more :program:`nova-novncproxy` service. Supports browser-based noVNC
|
||||
clients. For simple deployments, this service typically runs on the same
|
||||
machine as :program:`nova-api` because it operates as a proxy between the
|
||||
public network and the private compute host network.
|
||||
machine as :program:`nova-api-wsgi` because it operates as a proxy between
|
||||
the public network and the private compute host network.
|
||||
|
||||
- One or more :program:`nova-compute` services. Hosts the instances for which
|
||||
consoles are provided.
|
||||
@ -427,8 +427,8 @@ Here's the general flow of actions:
|
||||
|
||||
1. The user requests a serial console connection string for an instance
|
||||
from the REST API.
|
||||
2. The :program:`nova-api` service asks the :program:`nova-compute` service,
|
||||
which manages that instance, to fulfill that request.
|
||||
2. The :program:`nova-api-wsgi` service asks the :program:`nova-compute`
|
||||
service, which manages that instance, to fulfill that request.
|
||||
3. That connection string gets used by the user to connect to the
|
||||
:program:`nova-serialproxy` service.
|
||||
4. The :program:`nova-serialproxy` service then proxies the console interaction
|
||||
|
||||
@ -1365,7 +1365,7 @@ via the ``nova.api.extra_spec_validator`` `entrypoint`__.
|
||||
|
||||
The module containing your custom filter(s) must be packaged and available in
|
||||
the same environment(s) that the nova controllers, or specifically the
|
||||
:program:`nova-scheduler` and :program:`nova-api` services, are available in.
|
||||
:program:`nova-scheduler` and :program:`nova-api-wsgi` services, are available in.
|
||||
As an example, consider the following sample package, which is the `minimal
|
||||
structure`__ for a standard, setuptools-based Python package:
|
||||
|
||||
|
||||
@ -50,16 +50,16 @@ A Guru Meditation report is sent by the Compute service upon receipt of the
|
||||
general-purpose error report that includes details about the current state of
|
||||
the service. The error report is sent to ``stderr``.
|
||||
|
||||
For example, if you redirect error output to ``nova-api-err.log`` using
|
||||
:command:`nova-api 2>/var/log/nova/nova-api-err.log`, resulting in the process
|
||||
ID 8675, you can then run:
|
||||
For example, if you redirect error output to ``nova-compute-err.log`` using
|
||||
:command:`nova-compute 2>/var/log/nova/nova-compute-err.log`, resulting in the
|
||||
process ID 8675, you can then run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# kill -USR2 8675
|
||||
|
||||
This command triggers the Guru Meditation report to be printed to
|
||||
``/var/log/nova/nova-api-err.log``.
|
||||
``/var/log/nova/nova-compute-err.log``.
|
||||
|
||||
The report has the following sections:
|
||||
|
||||
|
||||
@ -112,7 +112,8 @@ Configuration
|
||||
-------------
|
||||
|
||||
To enable unified limits quotas, some Nova configuration of
|
||||
the :program:`nova-api` and :program:`nova-conductor` services is necessary.
|
||||
the :program:`nova-api-wsgi` and :program:`nova-conductor` services is
|
||||
necessary.
|
||||
|
||||
Set the quota driver to the ``nova.quota.UnifiedLimitsDriver``:
|
||||
|
||||
@ -416,7 +417,7 @@ the quota limit for that resource will be considered to be unlimited and all
|
||||
requests to allocate that resource will be accepted. Any resource not in the
|
||||
list will be considered to have 0 quota.
|
||||
|
||||
The options should be configured for the :program:`nova-api` and
|
||||
The options should be configured for the :program:`nova-api-wsgi` and
|
||||
:program:`nova-conductor` services. The :program:`nova-conductor` service
|
||||
performs quota enforcement when :oslo.config:option:`quota.recheck_quota` is
|
||||
``True`` (the default).
|
||||
|
||||
@ -29,8 +29,8 @@ Configuration
|
||||
|
||||
The service you must configure to enable the ``StaticJSON`` vendordata module
|
||||
depends on how guests are accessing vendordata. If using the metadata service,
|
||||
configuration applies to either :program:`nova-api` or
|
||||
:program:`nova-api-metadata`, depending on the deployment, while if using
|
||||
configuration applies to either :program:`nova-api-wsgi` or
|
||||
:program:`nova-metadata-wsgi`, depending on the deployment, while if using
|
||||
config drives, configuration applies to :program:`nova-compute`. However,
|
||||
configuration is otherwise the same and the following options apply:
|
||||
|
||||
@ -115,7 +115,7 @@ Configuration
|
||||
As with ``StaticJSON``, the service you must configure to enable the
|
||||
``DynamicJSON`` vendordata module depends on how guests are accessing
|
||||
vendordata. If using the metadata service, configuration applies to either
|
||||
:program:`nova-api` or :program:`nova-api-metadata`, depending on the
|
||||
:program:`nova-api-wsgi` or :program:`nova-metadata-wsgi`, depending on the
|
||||
deployment, while if using config drives, configuration applies to
|
||||
:program:`nova-compute`. However, configuration is otherwise the same and the
|
||||
following options apply:
|
||||
|
||||
@ -44,7 +44,6 @@ daemonize correctly after starting up.
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
nova-api
|
||||
nova-compute
|
||||
nova-conductor
|
||||
nova-novncproxy
|
||||
@ -55,15 +54,12 @@ daemonize correctly after starting up.
|
||||
WSGI Services
|
||||
-------------
|
||||
|
||||
Starting in the Pike release, the preferred way to deploy the nova api is in a
|
||||
Starting in the 2025.2 release, the only way to deploy the nova api is in a
|
||||
wsgi container (uwsgi or apache/mod_wsgi). These are the wsgi entry points to
|
||||
do that.
|
||||
do that:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
nova-api-metadata
|
||||
nova-api-os-compute
|
||||
* :doc:`nova-api-wsgi </user/wsgi>`
|
||||
* :doc:`nova-metadata-wsgi </user/wsgi>`
|
||||
|
||||
Additional Tools
|
||||
----------------
|
||||
|
||||
@ -1,52 +0,0 @@
|
||||
=================
|
||||
nova-api-metadata
|
||||
=================
|
||||
|
||||
.. program:: nova-api-metadata
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
::
|
||||
|
||||
nova-api-metadata [<options>...]
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
:program:`nova-api-metadata` is a server daemon that serves the Nova Metadata
|
||||
API. This daemon routes database requests via the ``nova-conductor`` service,
|
||||
so there are some considerations about using this in a
|
||||
:ref:`multi-cell layout <cells-v2-layout-metadata-api>`.
|
||||
|
||||
Options
|
||||
=======
|
||||
|
||||
.. rubric:: General options
|
||||
|
||||
.. include:: opts/common.rst
|
||||
|
||||
.. rubric:: Debugger options
|
||||
|
||||
.. include:: opts/debugger.rst
|
||||
|
||||
Files
|
||||
=====
|
||||
|
||||
* ``/etc/nova/nova.conf``
|
||||
* ``/etc/nova/api-paste.ini``
|
||||
* ``/etc/nova/policy.yaml``
|
||||
* ``/etc/nova/policy.d/``
|
||||
* ``/etc/nova/rootwrap.conf``
|
||||
* ``/etc/nova/rootwrap.d/``
|
||||
|
||||
See Also
|
||||
========
|
||||
|
||||
:doc:`nova-api(1) <nova-api>`,
|
||||
:doc:`nova-api-os-compute(1) <nova-api-os-compute>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
||||
* Nova bugs are managed at `Launchpad <https://bugs.launchpad.net/nova>`__
|
||||
@ -1,50 +0,0 @@
|
||||
===================
|
||||
nova-api-os-compute
|
||||
===================
|
||||
|
||||
.. program:: nova-api-os-compute
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
::
|
||||
|
||||
nova-api-os-compute [<options>...]
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
:program:`nova-api-os-compute` is a server daemon that serves the Nova
|
||||
OpenStack Compute API.
|
||||
|
||||
Options
|
||||
=======
|
||||
|
||||
.. rubric:: General options
|
||||
|
||||
.. include:: opts/common.rst
|
||||
|
||||
.. rubric:: Debugger options
|
||||
|
||||
.. include:: opts/debugger.rst
|
||||
|
||||
Files
|
||||
=====
|
||||
|
||||
* ``/etc/nova/nova.conf``
|
||||
* ``/etc/nova/api-paste.ini``
|
||||
* ``/etc/nova/policy.yaml``
|
||||
* ``/etc/nova/policy.d/``
|
||||
* ``/etc/nova/rootwrap.conf``
|
||||
* ``/etc/nova/rootwrap.d/``
|
||||
|
||||
See Also
|
||||
========
|
||||
|
||||
:doc:`nova-api(1) <nova-api>`,
|
||||
:doc:`nova-api-metadata(1) <nova-api-metadata>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
||||
* Nova bugs are managed at `Launchpad <https://bugs.launchpad.net/nova>`__
|
||||
@ -1,50 +0,0 @@
|
||||
========
|
||||
nova-api
|
||||
========
|
||||
|
||||
.. program:: nova-api
|
||||
|
||||
Synopsis
|
||||
========
|
||||
|
||||
::
|
||||
|
||||
nova-api [<options>...]
|
||||
|
||||
Description
|
||||
===========
|
||||
|
||||
:program:`nova-api` is a server daemon that serves the metadata and compute
|
||||
APIs in separate greenthreads.
|
||||
|
||||
Options
|
||||
=======
|
||||
|
||||
.. rubric:: General options
|
||||
|
||||
.. include:: opts/common.rst
|
||||
|
||||
.. rubric:: Debugger options
|
||||
|
||||
.. include:: opts/debugger.rst
|
||||
|
||||
Files
|
||||
=====
|
||||
|
||||
* ``/etc/nova/nova.conf``
|
||||
* ``/etc/nova/api-paste.ini``
|
||||
* ``/etc/nova/policy.yaml``
|
||||
* ``/etc/nova/policy.d/``
|
||||
* ``/etc/nova/rootwrap.conf``
|
||||
* ``/etc/nova/rootwrap.d/``
|
||||
|
||||
See Also
|
||||
========
|
||||
|
||||
:doc:`nova-api-metadata(1) <nova-api-metadata>`,
|
||||
:doc:`nova-api-os-compute(1) <nova-api-os-compute>`
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
||||
* Nova bugs are managed at `Launchpad <https://bugs.launchpad.net/nova>`__
|
||||
@ -28,7 +28,7 @@ You also need to let the nova user run :program:`nova-rootwrap` as root in
|
||||
|
||||
To make allowed commands node-specific, your packaging should only install
|
||||
``{compute,network}.filters`` respectively on compute and network nodes, i.e.
|
||||
:program:`nova-api` nodes should not have any of those files installed.
|
||||
:program:`nova-api-wsgi` nodes should not have any of those files installed.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@ -158,7 +158,7 @@ the defaults from the :doc:`install guide </install/index>` will be sufficient.
|
||||
a successful cells v2 layout.
|
||||
|
||||
* :doc:`Running nova-api on wsgi <user/wsgi>`: Considerations for using a real
|
||||
WSGI container instead of the baked-in eventlet web server.
|
||||
WSGI container.
|
||||
|
||||
.. # NOTE(amotoki): toctree needs to be placed at the end of the section to
|
||||
# keep the document structure in the PDF doc.
|
||||
|
||||
@ -18,12 +18,12 @@ images to launch instances.
|
||||
|
||||
OpenStack Compute consists of the following areas and their components:
|
||||
|
||||
``nova-api`` service
|
||||
``nova-api-wsgi`` service
|
||||
Accepts and responds to end user compute API calls. The service supports the
|
||||
OpenStack Compute API. It enforces some policies and initiates most
|
||||
orchestration activities, such as running an instance.
|
||||
|
||||
``nova-api-metadata`` service
|
||||
``nova-metadata-wsgi`` service
|
||||
Accepts metadata requests from instances. For more information, refer to
|
||||
:doc:`/admin/metadata-service`.
|
||||
|
||||
|
||||
@ -1,10 +1,8 @@
|
||||
Using WSGI with Nova
|
||||
====================
|
||||
|
||||
Though the compute and metadata APIs can be run using independent scripts that
|
||||
provide eventlet-based HTTP servers, it is generally considered more performant
|
||||
and flexible to run them using a generic HTTP server that supports WSGI_ (such
|
||||
as Apache_ or nginx_).
|
||||
Since the version 2025.2 the only way to run the compute API and metadata API
|
||||
is using a generic HTTP server that supports WSGI_ (such as Apache_ or nginx_).
|
||||
|
||||
The nova project provides two automatically generated entry points that
|
||||
support this: ``nova-api-wsgi`` and ``nova-metadata-wsgi``. These read
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user