========================
Compute service overview
========================

Use OpenStack Compute to host and manage cloud computing systems.
OpenStack Compute is a major part of an :term:`Infrastructure-as-a-Service
(IaaS)` system. The main modules are implemented in Python.

OpenStack Compute interacts with OpenStack Identity for authentication;
OpenStack Image service for disk and server images; and OpenStack
dashboard for the user and administrative interface. Image access is
limited by projects, and by 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:

``nova-api`` service
  Accepts and responds to end user compute API calls. The service
  supports the OpenStack Compute API, the Amazon EC2 API, and a
  special Admin API for privileged users to perform administrative
  actions. It enforces some policies and initiates most orchestration
  activities, such as running an instance.

``nova-api-metadata`` service
  Accepts metadata requests from instances. The ``nova-api-metadata``
  service is generally used when you run in multi-host mode with
  ``nova-network`` installations. For details, see `Metadata
  service <http://docs.openstack.org/admin-guide/compute-networking-nova.html#metadata-service>`__
  in the OpenStack Administrator Guide.

``nova-compute`` service
  A worker daemon that creates and terminates virtual machine
  instances through hypervisor APIs. For example:

  - XenAPI for XenServer/XCP

  - libvirt for KVM or QEMU

  - VMwareAPI for VMware

  Processing is fairly complex. Basically, the daemon accepts actions
  from the queue and performs a series of system commands such as
  launching a KVM instance and updating its state in the database.

``nova-scheduler`` service
  Takes a virtual machine instance request from the queue and
  determines on which compute server host it runs.

``nova-conductor`` module
  Mediates interactions between the ``nova-compute`` service and the
  database. It eliminates direct accesses to the cloud database made
  by the ``nova-compute`` service. The ``nova-conductor`` module scales
  horizontally. However, do not deploy it on nodes where the
  ``nova-compute`` service runs. For more information, see `Configuration
  Reference Guide <http://docs.openstack.org/mitaka/config-reference/compute/conductor.html>`__.

``nova-cert`` module
  A server daemon that serves the Nova Cert service for X509
  certificates. Used to generate certificates for
  ``euca-bundle-image``. Only needed for the EC2 API.

``nova-network worker`` daemon
  Similar to the ``nova-compute`` service, accepts networking tasks from
  the queue and manipulates the network. Performs tasks such as
  setting up bridging interfaces or changing IPtables rules.

``nova-consoleauth`` daemon
  Authorizes tokens for users that console proxies provide. See
  ``nova-novncproxy`` and ``nova-xvpvncproxy``. This service must be running
  for console proxies to work. You can run proxies of either type
  against a single nova-consoleauth service in a cluster
  configuration. For information, see `About
  nova-consoleauth <http://docs.openstack.org/admin-guide/compute-remote-console-access.html#about-nova-consoleauth>`__.

``nova-novncproxy`` daemon
  Provides a proxy for accessing running instances through a VNC
  connection. Supports browser-based novnc clients.

``nova-spicehtml5proxy`` daemon
  Provides a proxy for accessing running instances through a SPICE
  connection. Supports browser-based HTML5 client.

``nova-xvpvncproxy`` daemon
  Provides a proxy for accessing running instances through a VNC
  connection. Supports an OpenStack-specific Java client.

``nova-cert`` daemon
  x509 certificates.

``nova`` client
  Enables users to submit commands as a tenant administrator or end
  user.

The queue
  A central hub for passing messages between daemons. Usually
  implemented with `RabbitMQ <http://www.rabbitmq.com/>`__, also can be
  implemented with another AMQP message queue, such as `ZeroMQ <http://www.zeromq.org/>`__.

SQL database
  Stores most build-time and run-time states for a cloud
  infrastructure, including:

  -  Available instance types

  -  Instances in use

  -  Available networks

  -  Projects

  Theoretically, OpenStack Compute can support any database that
  SQL-Alchemy supports. Common databases are SQLite3 for test and
  development work, MySQL, MariaDB, and PostgreSQL.