diff --git a/doc/source/_extra/.htaccess b/doc/source/_extra/.htaccess index 62904edd2a24..e0f1d13c991d 100644 --- a/doc/source/_extra/.htaccess +++ b/doc/source/_extra/.htaccess @@ -75,9 +75,10 @@ redirectmatch 301 ^/nova/([^/]+)/user/placement.html$ /placement/$1/ redirectmatch 301 ^/nova/([^/]+)/user/upgrade.html$ /nova/$1/admin/upgrades.html redirectmatch 301 ^/nova/([^/]+)/user/user-data.html$ /nova/$1/user/metadata.html redirectmatch 301 ^/nova/([^/]+)/user/vendordata.html$ /nova/$1/user/metadata.html +redirectmatch 301 ^/nova/([^/]+)/user/wsgi.html$ /nova/$1/admin/wsgi.html redirectmatch 301 ^/nova/([^/]+)/vendordata.html$ /nova/$1/user/metadata.html redirectmatch 301 ^/nova/([^/]+)/vmstates.html$ /nova/$1/reference/vm-states.html -redirectmatch 301 ^/nova/([^/]+)/wsgi.html$ /nova/$1/user/wsgi.html +redirectmatch 301 ^/nova/([^/]+)/wsgi.html$ /nova/$1/admin/wsgi.html redirectmatch 301 ^/nova/([^/]+)/admin/arch.html$ /nova/$1/admin/architecture.html redirectmatch 301 ^/nova/([^/]+)/admin/adv-config.html$ /nova/$1/admin/index.html redirectmatch 301 ^/nova/([^/]+)/admin/configuration/schedulers.html$ /nova/$1/admin/scheduling.html diff --git a/doc/source/admin/cells.rst b/doc/source/admin/cells.rst index 09d3008ebad1..01330b8d66b4 100644 --- a/doc/source/admin/cells.rst +++ b/doc/source/admin/cells.rst @@ -19,7 +19,7 @@ Laski gave at the Austin (Newton) summit which may be worth watching. .. note:: Cells v2 is different to the cells feature found in earlier versions of - nova, also known as cells v1. Cells v1 was deprecated in 16.0.0 (Pike) and + nova, also known as Cells v1. Cells v1 was deprecated in 16.0.0 (Pike) and removed entirely in Train (20.0.0). @@ -34,14 +34,13 @@ 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-wsgi` service which provides the external REST API to - users. +- The Compute API 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-wsgi` and +- An "API database" that is used primarily by the Compute API 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. @@ -268,8 +267,8 @@ database schemas, respectively. API database ~~~~~~~~~~~~ -The API database is the database used for API-level services, such as -:program:`nova-api-wsgi` and, in a multi-cell deployment, the superconductor. +The API database is the database used for API-level services, such as the +Compute API 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. @@ -797,22 +796,21 @@ Starting from the 19.0.0 (Stein) release, the :doc:`nova metadata API service .. rubric:: Global 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 +globally by setting :oslo.config:option:`api.local_metadata_per_cell` to +``false``. 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-metadata-wsgi` service, in this case. +information. .. rubric:: Local per cell Running Nova metadata API per cell can have better performance and data isolation in a multi-cell deployment. If your networks are segmented along -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 +cell boundaries, then you can run Nova metadata API service per cell by setting +:oslo.config:option:`api.local_metadata_per_cell` to ``true``. If you choose to +run it per cell, you should also configure each :neutron-doc:`neutron-metadata-agent ` service to -point to the corresponding :program:`nova-metadata-wsgi`. The nova metadata API -service **must** be run as a standalone service, using the -:program:`nova-metadata-wsgi` service, in this case. +point to the hostname/IP address of the corresponding Compute Metadata API. Console proxies ~~~~~~~~~~~~~~~ @@ -1024,7 +1022,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-wsgi` service worker so you + The cell mappings are cached in the compute API 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 diff --git a/doc/source/admin/index.rst b/doc/source/admin/index.rst index a856075afcae..1f5202ad7fe0 100644 --- a/doc/source/admin/index.rst +++ b/doc/source/admin/index.rst @@ -28,12 +28,12 @@ responsibilities of services and drivers are: .. rubric:: Services -:doc:`nova-metadata-wsgi ` - A WSGI application that serves the Nova Metadata API. - -:doc:`nova-api-wsgi ` +:doc:`Compute API ` A WSGI application that serves the Nova OpenStack Compute API. +:doc:`Metadata API ` + A WSGI application that serves the Nova Metadata API. + :doc:`nova-compute ` Manages virtual machines. Loads a Service object, and exposes the public methods on ComputeManager through a Remote Procedure Call (RPC). @@ -102,8 +102,8 @@ the defaults from the :doc:`install guide ` will be sufficient. * :placement-doc:`Placement service <>`: Overview of the placement service, including how it fits in with the rest of nova. -* :doc:`Running nova-api on wsgi `: Considerations for using a real - WSGI container instead of the baked-in eventlet web server. +* :doc:`Running nova-api on wsgi `: Considerations for deploying + the APIs. * :doc:`Nova service concurrency `: Considerations on how to use and tune Nova services in threading mode. diff --git a/doc/source/admin/pci-passthrough.rst b/doc/source/admin/pci-passthrough.rst index b7ea69fd931b..0be753704554 100644 --- a/doc/source/admin/pci-passthrough.rst +++ b/doc/source/admin/pci-passthrough.rst @@ -291,7 +291,7 @@ Refer to :oslo.config:option:`pci.alias` for syntax information. Refer to :ref:`Affinity ` for ``numa_policy`` information. -Once configured, restart the :program:`nova-api-wsgi` service. +Once configured, restart the Compute API service. Configuring a flavor or image diff --git a/doc/source/admin/remote-console-access.rst b/doc/source/admin/remote-console-access.rst index 828b50193639..9fdd754e01cb 100644 --- a/doc/source/admin/remote-console-access.rst +++ b/doc/source/admin/remote-console-access.rst @@ -52,7 +52,7 @@ 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-wsgi` because it operates as a proxy between + machine as the Compute API 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 @@ -427,7 +427,7 @@ 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-wsgi` service asks the :program:`nova-compute` +2. The Compute API 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. diff --git a/doc/source/admin/scheduling.rst b/doc/source/admin/scheduling.rst index 72f23e11df58..c0376bc3bbcb 100644 --- a/doc/source/admin/scheduling.rst +++ b/doc/source/admin/scheduling.rst @@ -1373,7 +1373,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-wsgi` services, are available in. +:program:`nova-scheduler` and Compute API services, are available in. As an example, consider the following sample package, which is the `minimal structure`__ for a standard, setuptools-based Python package: diff --git a/doc/source/admin/support-compute.rst b/doc/source/admin/support-compute.rst index 5acfe33b74ac..f1dff80e6473 100644 --- a/doc/source/admin/support-compute.rst +++ b/doc/source/admin/support-compute.rst @@ -61,13 +61,14 @@ process ID 8675, you can then run: This command triggers the Guru Meditation report to be printed to ``/var/log/nova/nova-compute-err.log``. -For WSGI based services like ``nova-api-wsgi`` and ``nova-metadata-wsgi`` using +For the WSGI-based compute API and metadata API services, using signals is not trivial due to the web server's own signal handling. An alternative to the signal-based approach that works equally well for freestanding and hosted entry points is to use a file-based trigger. Configure the service to trigger the GMR by the modification time changes of a file or directory. + .. code-block:: [oslo_reports] @@ -75,6 +76,7 @@ a file or directory. Then the report can be triggered by touching the file or directory. The GMRb will be emitted in the same place where the service logs normally. + .. code-block:: console touch /var/lib/nova @@ -83,6 +85,7 @@ Note that some web servers freeze the request handler processes when there is no HTTP request to be handled. This prevent the file system monitoring loop to detect the change. So after touching the file make a HTTP request to the given WSGI application. + .. code-block:: console openstack compute service list diff --git a/doc/source/admin/unified-limits.rst b/doc/source/admin/unified-limits.rst index 7dba5dd77098..1e34997b7774 100644 --- a/doc/source/admin/unified-limits.rst +++ b/doc/source/admin/unified-limits.rst @@ -111,9 +111,8 @@ scopes in order to perform actions with unified limits. Configuration ------------- -To enable unified limits quotas, some Nova configuration of -the :program:`nova-api-wsgi` and :program:`nova-conductor` services is -necessary. +To enable unified limits quotas, some Nova configuration of the Compute API and +:program:`nova-conductor` services is necessary. Set the quota driver to the ``nova.quota.UnifiedLimitsDriver``: @@ -417,7 +416,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-wsgi` and +The options should be configured for the Compute API and :program:`nova-conductor` services. The :program:`nova-conductor` service performs quota enforcement when :oslo.config:option:`quota.recheck_quota` is ``True`` (the default). diff --git a/doc/source/admin/vendordata.rst b/doc/source/admin/vendordata.rst index 6dcebcd21dce..60c21297c76b 100644 --- a/doc/source/admin/vendordata.rst +++ b/doc/source/admin/vendordata.rst @@ -29,10 +29,10 @@ 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-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: +configuration applies to either the compute API or metadata API 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: - :oslo.config:option:`api.vendordata_providers` - :oslo.config:option:`api.vendordata_jsonfile_path` @@ -114,11 +114,10 @@ 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-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: +vendordata. If using the metadata service, configuration applies to either the +compute API or metadata API 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: - :oslo.config:option:`api.vendordata_providers` - :oslo.config:option:`api.vendordata_dynamic_ssl_certfile` diff --git a/doc/source/admin/wsgi.rst b/doc/source/admin/wsgi.rst new file mode 100644 index 000000000000..b169e19b7b73 --- /dev/null +++ b/doc/source/admin/wsgi.rst @@ -0,0 +1,49 @@ +Using WSGI with Nova +==================== + +.. versionchanged:: 33.0.0 + + Removed support for the eventlet server scripts, ``nova-api``, + ``nova-api-metadata`` and ``nova-api-os-compute``. Only WSGI-based + deployments are supported going forward and it is no longer possible to run + the compute API and metadata APIs in the same process, as it was with the + eventlet scripts. + +.. versionchanged:: 33.0.0 + + Removed the ``nova-api-wsgi`` and ``nova-metadata-wsgi`` WSGI scripts + previously provided by Nova. Deployment tooling should instead reference + the Python module paths for these services, ``nova.wsgi.osapi_compute`` and + ``nova.wsgi.metadata``, if their chosen WSGI server supports this + (gunicorn, uWSGI) or implement a ``.wsgi`` script themselves if not + (mod_wsgi). + +Nova provides two APIs: a compute API (a.k.a. the REST API) and a +:doc:`metadata API `. Both of these APIs are implemented as +generic Python HTTP servers that implement WSGI_ and are expected to be +deployed using a server with WSGI support. + +To facilitate this, Nova provides a WSGI module for each API that provide the +``application`` object that most WSGI servers require. These can be found at +``nova.wsgi.osapi_compute`` and ``nova.wsgi.metadata`` for the compute API and +the metadata API, respectively. The ``application`` objects are automatically +configured with configuration from ``nova.conf`` and ``api-paste.ini`` by +default, and the the config files and config directory can be overridden via +the ``OS_NOVA_CONFIG_FILES`` and ``OS_NOVA_CONFIG_DIR`` environment variables. + +.. note:: + + File paths listed in ``OS_NOVA_CONFIG_FILES`` are relative to + ``OS_NOVA_CONFIG_DIR`` and delimited by ``;``. + +DevStack deploys the compute and metadata APIs behind Apache using uwsgi_ via +mod_proxy_uwsgi_. Inspecting the configuration created there can provide some +guidance on one option for managing the WSGI scripts. It is important to +remember, however, that one of the major features of using WSGI is that there +are many different ways to host a WSGI application. Different servers make +different choices about performance and configurability. It is up to you, as a +deployer, to choose an appropriate server for your deployment. + +.. _WSGI: https://www.python.org/dev/peps/pep-3333/ +.. _uwsgi: https://uwsgi-docs.readthedocs.io/ +.. _mod_proxy_uwsgi: http://uwsgi-docs.readthedocs.io/en/latest/Apache.html#mod-proxy-uwsgi diff --git a/doc/source/cli/index.rst b/doc/source/cli/index.rst index 1063d247b2b9..bc7c8352e17e 100644 --- a/doc/source/cli/index.rst +++ b/doc/source/cli/index.rst @@ -54,12 +54,9 @@ daemonize correctly after starting up. WSGI Services ------------- -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: - -* :doc:`nova-api-wsgi ` -* :doc:`nova-metadata-wsgi ` +Starting in the 2025.2 release, the only way to deploy the compute and metadata +APIs is via WSGI (uwsgi or apache/mod_wsgi). Refer to :doc:`/admin/wsgi` for +more information. Additional Tools ---------------- diff --git a/doc/source/cli/nova-rootwrap.rst b/doc/source/cli/nova-rootwrap.rst index cdf699096df2..5033783bc55e 100644 --- a/doc/source/cli/nova-rootwrap.rst +++ b/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-wsgi` nodes should not have any of those files installed. +API nodes should not have any of those files installed. .. note:: diff --git a/doc/source/index.rst b/doc/source/index.rst index d5b40c4c0571..40278f00acdd 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -157,8 +157,8 @@ the defaults from the :doc:`install guide ` will be sufficient. cells allow sharding of your compute environment. Upfront planning is key to a successful cells v2 layout. -* :doc:`Running nova-api on wsgi `: Considerations for using a real - WSGI container. +* :doc:`Running nova-api on wsgi `: Considerations for deploying + under WSGI. .. # NOTE(amotoki): toctree needs to be placed at the end of the section to # keep the document structure in the PDF doc. @@ -168,7 +168,7 @@ the defaults from the :doc:`install guide ` will be sufficient. user/feature-classification user/support-matrix admin/cells - user/wsgi + admin/wsgi Maintenance ----------- diff --git a/doc/source/install/get-started-compute.rst b/doc/source/install/get-started-compute.rst index 75a7432670ce..358432f3a182 100644 --- a/doc/source/install/get-started-compute.rst +++ b/doc/source/install/get-started-compute.rst @@ -16,24 +16,22 @@ users; quotas are limited per project (the number of instances, for example). OpenStack Compute can scale horizontally on standard hardware, and download images to launch instances. -OpenStack Compute consists of the following areas and their components: +OpenStack Compute consists of two :doc:`WSGI ` APIs and a number +of services: -``nova-api-wsgi`` service +Compute API 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-metadata-wsgi`` service +Metadata API Accepts metadata requests from instances. For more information, refer to :doc:`/admin/metadata-service`. ``nova-compute`` service A worker daemon that creates and terminates virtual machine instances through - hypervisor APIs. For example: - - - libvirt for KVM or QEMU - - - VMwareAPI for VMware + hypervisor APIs. The default hypervisor is libvirt with KVM or QEMU, but + other hypervisors are supported. Processing is fairly complex. Basically, the daemon accepts actions from the queue and performs a series of system commands such as launching a KVM diff --git a/doc/source/user/wsgi.rst b/doc/source/user/wsgi.rst deleted file mode 100644 index bbc69ec33385..000000000000 --- a/doc/source/user/wsgi.rst +++ /dev/null @@ -1,40 +0,0 @@ -Using WSGI with Nova -==================== - -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 -``nova.conf`` and ``api-paste.ini`` by default and generate the required -module-level ``application`` that most WSGI servers require. -If nova is installed using pip, these two scripts will be installed into -whatever the expected ``bin`` directory is for the environment. - -The config files and config directory can be overridden via the -``OS_NOVA_CONFIG_FILES`` and ``OS_NOVA_CONFIG_DIR`` environment variables. -File paths listed in ``OS_NOVA_CONFIG_FILES`` are relative to -``OS_NOVA_CONFIG_DIR`` and delimited by ``;``. - - -The new scripts replace older experimental scripts that could be found in the -``nova/wsgi`` directory of the code repository. The new scripts are *not* -experimental. - -When running the compute and metadata services with WSGI, sharing the compute -and metadata service in the same process is not supported (as it is in the -eventlet-based scripts). - -In devstack as of May 2017, the compute and metadata APIs are hosted by a -Apache communicating with uwsgi_ via mod_proxy_uwsgi_. Inspecting the -configuration created there can provide some guidance on one option for -managing the WSGI scripts. It is important to remember, however, that one of -the major features of using WSGI is that there are many different ways to host -a WSGI application. Different servers make different choices about performance -and configurability. - -.. _WSGI: https://www.python.org/dev/peps/pep-3333/ -.. _apache: http://httpd.apache.org/ -.. _nginx: http://nginx.org/en/ -.. _uwsgi: https://uwsgi-docs.readthedocs.io/ -.. _mod_proxy_uwsgi: http://uwsgi-docs.readthedocs.io/en/latest/Apache.html#mod-proxy-uwsgi diff --git a/doc/test/redirect-tests.txt b/doc/test/redirect-tests.txt index 6c28e790422b..7fde8804dd9c 100644 --- a/doc/test/redirect-tests.txt +++ b/doc/test/redirect-tests.txt @@ -76,9 +76,10 @@ /nova/latest/user/user-data.html 301 /nova/latest/user/metadata.html /nova/latest/user/upgrade.html 301 /nova/latest/admin/upgrades.html /nova/latest/user/vendordata.html 301 /nova/latest/user/metadata.html +/nova/latest/user/wsgi.html 301 /nova/latest/admin/wsgi.html /nova/latest/vendordata.html 301 /nova/latest/user/metadata.html /nova/latest/vmstates.html 301 /nova/latest/reference/vm-states.html -/nova/latest/wsgi.html 301 /nova/latest/user/wsgi.html +/nova/latest/wsgi.html 301 /nova/latest/admin/wsgi.html /nova/latest/admin/arch.html 301 /nova/latest/admin/architecture.html /nova/latest/admin/adv-config.html 301 /nova/latest/admin/index.html /nova/latest/admin/configuration/schedulers.html 301 /nova/latest/admin/scheduling.html diff --git a/nova/api/metadata/wsgi.py b/nova/api/metadata/wsgi.py deleted file mode 100644 index d2f33c2d6fee..000000000000 --- a/nova/api/metadata/wsgi.py +++ /dev/null @@ -1,20 +0,0 @@ -# Licensed under the Apache License, Version 2.0 (the "License"); you may -# not use this file except in compliance with the License. You may obtain -# a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT -# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the -# License for the specific language governing permissions and limitations -# under the License. -"""WSGI application entry-point for Nova Metadata API, installed by pbr.""" - -from nova.api.openstack import wsgi_app - -NAME = "metadata" - - -def init_application(): - return wsgi_app.init_application(NAME) diff --git a/nova/api/openstack/compute/wsgi.py b/nova/api/openstack/compute/wsgi.py deleted file mode 100644 index 0ecb5e8d52b3..000000000000 --- a/nova/api/openstack/compute/wsgi.py +++ /dev/null @@ -1,20 +0,0 @@ -# Licensed under the Apache License, Version 2.0 (the "License"); you may -# not use this file except in compliance with the License. You may obtain -# a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT -# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the -# License for the specific language governing permissions and limitations -# under the License. -"""WSGI application entry-point for Nova Compute API, installed by pbr.""" - -from nova.api.openstack import wsgi_app - -NAME = "osapi_compute" - - -def init_application(): - return wsgi_app.init_application(NAME) diff --git a/releasenotes/notes/remove-wsgi-scripts-577090db75ecbade.yaml b/releasenotes/notes/remove-wsgi-scripts-577090db75ecbade.yaml new file mode 100644 index 000000000000..34fe4d1efe73 --- /dev/null +++ b/releasenotes/notes/remove-wsgi-scripts-577090db75ecbade.yaml @@ -0,0 +1,9 @@ +--- +upgrade: + - | + The WSGI scripts, ``nova-api-wsgi`` and ``nova-metadata-wsgi``, have been + removed. Deployment tooling should instead reference the Python module + paths for these services, ``nova.wsgi.osapi_compute`` and + ``nova.wsgi.metadata``, if their chosen WSGI server supports this + (gunicorn, uWSGI) or implement a ``.wsgi`` script themselves if not + (mod_wsgi). diff --git a/setup.cfg b/setup.cfg index 255a5defcc98..9d837850ba86 100644 --- a/setup.cfg +++ b/setup.cfg @@ -84,9 +84,6 @@ console_scripts = nova-serialproxy = nova.cmd.serialproxy:main nova-spicehtml5proxy = nova.cmd.spicehtml5proxy:main nova-status = nova.cmd.status:main -wsgi_scripts = - nova-api-wsgi = nova.api.openstack.compute.wsgi:init_application - nova-metadata-wsgi = nova.api.metadata.wsgi:init_application [mypy] show_column_numbers = true