[doc]Remove eventlet based API endpoints

The previous patch[1] removed the entry points. As there is sizable
amount of doc change needed to remove all the references from the doc
to the removed entry points a separate patch, this, is created to do so.

[1] Ie758550c0b8fb02aeb398396961467d9f845fcc9

Change-Id: Ibe8e45e86912e747f07e5fabd5b1204341c1e606

doc/source/admin/cells.rst

@@ -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

doc/source/admin/index.rst

@@ -28,15 +28,11 @@ responsibilities of services and drivers are:
 
 .. rubric:: Services
 
-:doc:`nova-api-metadata </cli/nova-api-metadata>`
+:doc:`nova-metadata-wsgi </user/wsgi>`
-  A server daemon that serves the Nova Metadata API.
+  A WSGI application that serves the Nova Metadata API.
 
-:doc:`nova-api-os-compute </cli/nova-api-os-compute>`
+:doc:`nova-api-wsgi </user/wsgi>`
-  A server daemon that serves the Nova OpenStack Compute API.
+  A WSGI application 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-compute </cli/nova-compute>`
   Manages virtual machines. Loads a Service object, and exposes the public

doc/source/admin/metadata-service.rst

@@ -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`
+The metadata service can be run globally, or on a per-cell basis. A detailed
-application, or on a per-cell basis, as part of the standalone
+comparison is provided in the
-:program:`nova-api-metadata` application. A detailed comparison is provided in
+:ref:`cells V2 guide <cells-v2-layout-metadata-api>`.
-the :ref:`cells V2 guide <cells-v2-layout-metadata-api>`.
 
 .. versionchanged:: 19.0.0
 

doc/source/admin/pci-passthrough.rst

@@ -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

doc/source/admin/remote-console-access.rst

@@ -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
+  machine as :program:`nova-api-wsgi` because it operates as a proxy between
-  public network and the private compute host network.
+  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,
+2. The :program:`nova-api-wsgi` service asks the :program:`nova-compute`
-   which manages that instance, to fulfill that request.
+   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

doc/source/admin/scheduling.rst

@@ -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:
 

doc/source/admin/support-compute.rst

@@ -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
+For example, if you redirect error output to ``nova-compute-err.log`` using
-:command:`nova-api 2>/var/log/nova/nova-api-err.log`, resulting in the process
+:command:`nova-compute 2>/var/log/nova/nova-compute-err.log`, resulting in the
-ID 8675, you can then run:
+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:
 

doc/source/admin/unified-limits.rst

@@ -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).

doc/source/admin/vendordata.rst

@@ -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
+configuration applies to either :program:`nova-api-wsgi` or
-:program:`nova-api-metadata`, depending on the deployment, while if using
+: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:

doc/source/cli/index.rst

@@ -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::
+* :doc:`nova-api-wsgi </user/wsgi>`
-   :maxdepth: 1
+* :doc:`nova-metadata-wsgi </user/wsgi>`
-
-   nova-api-metadata
-   nova-api-os-compute
 
 Additional Tools
 ----------------

doc/source/cli/nova-api-metadata.rst

@@ -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>`__

doc/source/cli/nova-api-os-compute.rst

@@ -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>`__

doc/source/cli/nova-api.rst

@@ -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>`__

doc/source/cli/nova-rootwrap.rst

@@ -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::
 

doc/source/index.rst

@@ -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.

doc/source/install/get-started-compute.rst

@@ -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`.
 

doc/source/user/wsgi.rst

@@ -1,10 +1,8 @@
 Using WSGI with Nova
 ====================
 
-Though the compute and metadata APIs can be run using independent scripts that
+Since the version 2025.2 the only way to run the compute API and metadata API
-provide eventlet-based HTTP servers, it is generally considered more performant
+is using a generic HTTP server that supports WSGI_ (such as Apache_ or nginx_).
-and flexible to run them 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