diff --git a/doc/source/admin/configuration/cells.rst b/doc/source/admin/configuration/cells.rst deleted file mode 100644 index ddc2c1775a..0000000000 --- a/doc/source/admin/configuration/cells.rst +++ /dev/null @@ -1,295 +0,0 @@ -========== -Cells (v1) -========== - -.. warning:: - - Configuring and implementing Cells v1 is not recommended for new deployments - of the Compute service (nova). Cells v2 replaces cells v1, and v2 is - required to install or upgrade the Compute service to the 15.0.0 Ocata - release. More information on cells v2 can be found in :doc:`/user/cells`. - -`Cells` functionality enables you to scale an OpenStack Compute cloud in a more -distributed fashion without having to use complicated technologies like -database and message queue clustering. It supports very large deployments. - -When this functionality is enabled, the hosts in an OpenStack Compute cloud are -partitioned into groups called cells. Cells are configured as a tree. The -top-level cell should have a host that runs a ``nova-api`` service, but no -``nova-compute`` services. Each child cell should run all of the typical -``nova-*`` services in a regular Compute cloud except for ``nova-api``. You can -think of cells as a normal Compute deployment in that each cell has its own -database server and message queue broker. - -The ``nova-cells`` service handles communication between cells and selects -cells for new instances. This service is required for every cell. Communication -between cells is pluggable, and currently the only option is communication -through RPC. - -Cells scheduling is separate from host scheduling. ``nova-cells`` first picks -a cell. Once a cell is selected and the new build request reaches its -``nova-cells`` service, it is sent over to the host scheduler in that cell and -the build proceeds as it would have without cells. - -Cell configuration options -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. todo:: This is duplication. We should be able to use the - oslo.config.sphinxext module to generate this for us - -Cells are disabled by default. All cell-related configuration options appear in -the ``[cells]`` section in ``nova.conf``. The following cell-related options -are currently supported: - -``enable`` - Set to ``True`` to turn on cell functionality. Default is ``false``. - -``name`` - Name of the current cell. Must be unique for each cell. - -``capabilities`` - List of arbitrary ``key=value`` pairs defining capabilities of the current - cell. Values include ``hypervisor=xenserver;kvm,os=linux;windows``. - -``call_timeout`` - How long in seconds to wait for replies from calls between cells. - -``scheduler_filter_classes`` - Filter classes that the cells scheduler should use. By default, uses - ``nova.cells.filters.all_filters`` to map to all cells filters included with - Compute. - -``scheduler_weight_classes`` - Weight classes that the scheduler for cells uses. By default, uses - ``nova.cells.weights.all_weighers`` to map to all cells weight algorithms - included with Compute. - -``ram_weight_multiplier`` - Multiplier used to weight RAM. Negative numbers indicate that Compute should - stack VMs on one host instead of spreading out new VMs to more hosts in the - cell. The default value is 10.0. - -Configure the API (top-level) cell -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The cell type must be changed in the API cell so that requests can be proxied -through ``nova-cells`` down to the correct cell properly. Edit the -``nova.conf`` file in the API cell, and specify ``api`` in the ``cell_type`` -key: - -.. code-block:: ini - - [DEFAULT] - compute_api_class=nova.compute.cells_api.ComputeCellsAPI - # ... - - [cells] - cell_type= api - -Configure the child cells -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Edit the ``nova.conf`` file in the child cells, and specify ``compute`` in the -``cell_type`` key: - -.. code-block:: ini - - [DEFAULT] - # Disable quota checking in child cells. Let API cell do it exclusively. - quota_driver=nova.quota.NoopQuotaDriver - - [cells] - cell_type = compute - -Configure the database in each cell -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Before bringing the services online, the database in each cell needs to be -configured with information about related cells. In particular, the API cell -needs to know about its immediate children, and the child cells must know about -their immediate agents. The information needed is the ``RabbitMQ`` server -credentials for the particular cell. - -Use the :command:`nova-manage cell create` command to add this information to -the database in each cell: - -.. code-block:: console - - # nova-manage cell create -h - usage: nova-manage cell create [-h] [--name ] - [--cell_type ] - [--username ] [--password ] - [--broker_hosts ] - [--hostname ] [--port ] - [--virtual_host ] - [--woffset ] [--wscale ] - - optional arguments: - -h, --help show this help message and exit - --name Name for the new cell - --cell_type - Whether the cell is parent/api or child/compute - --username - Username for the message broker in this cell - --password - Password for the message broker in this cell - --broker_hosts - Comma separated list of message brokers in this cell. - Each Broker is specified as hostname:port with both - mandatory. This option overrides the --hostname and - --port options (if provided). - --hostname - Address of the message broker in this cell - --port Port number of the message broker in this cell - --virtual_host - The virtual host of the message broker in this cell - --woffset - --wscale - -As an example, assume an API cell named ``api`` and a child cell named -``cell1``. - -Within the ``api`` cell, specify the following ``RabbitMQ`` server information: - -.. code-block:: ini - - rabbit_host=10.0.0.10 - rabbit_port=5672 - rabbit_username=api_user - rabbit_password=api_passwd - rabbit_virtual_host=api_vhost - -Within the ``cell1`` child cell, specify the following ``RabbitMQ`` server -information: - -.. code-block:: ini - - rabbit_host=10.0.1.10 - rabbit_port=5673 - rabbit_username=cell1_user - rabbit_password=cell1_passwd - rabbit_virtual_host=cell1_vhost - -You can run this in the API cell as root: - -.. code-block:: console - - # nova-manage cell create --name cell1 --cell_type child \ - --username cell1_user --password cell1_passwd --hostname 10.0.1.10 \ - --port 5673 --virtual_host cell1_vhost --woffset 1.0 --wscale 1.0 - -Repeat the previous steps for all child cells. - -In the child cell, run the following, as root: - -.. code-block:: console - - # nova-manage cell create --name api --cell_type parent \ - --username api_user --password api_passwd --hostname 10.0.0.10 \ - --port 5672 --virtual_host api_vhost --woffset 1.0 --wscale 1.0 - -To customize the Compute cells, use the configuration option settings -documented above. - -Cell scheduling configuration -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To determine the best cell to use to launch a new instance, Compute uses a set -of filters and weights defined in the ``/etc/nova/nova.conf`` file. The -following options are available to prioritize cells for scheduling: - -``scheduler_filter_classes`` - List of filter classes. By default ``nova.cells.filters.all_filters`` - is specified, which maps to all cells filters included with Compute - (see the section called :ref:`Filters `). - -``scheduler_weight_classes`` - List of weight classes. By default ``nova.cells.weights.all_weighers`` is - specified, which maps to all cell weight algorithms included with Compute. - The following modules are available: - - ``mute_child`` - Downgrades the likelihood of child cells being chosen for scheduling - requests, which haven't sent capacity or capability updates in a while. - Options include ``mute_weight_multiplier`` (multiplier for mute children; - value should be negative). - - ``ram_by_instance_type`` - Select cells with the most RAM capacity for the instance type being - requested. Because higher weights win, Compute returns the number of - available units for the instance type requested. The - ``ram_weight_multiplier`` option defaults to 10.0 that adds to the weight - by a factor of 10. - - Use a negative number to stack VMs on one host instead of spreading - out new VMs to more hosts in the cell. - - ``weight_offset`` - Allows modifying the database to weight a particular cell. You can use this - when you want to disable a cell (for example, '0'), or to set a default - cell by making its ``weight_offset`` very high (for example, - ``999999999999999``). The highest weight will be the first cell to be - scheduled for launching an instance. - -Additionally, the following options are available for the cell scheduler: - -``scheduler_retries`` - Specifies how many times the scheduler tries to launch a new instance when no - cells are available (default=10). - -``scheduler_retry_delay`` - Specifies the delay (in seconds) between retries (default=2). - -As an admin user, you can also add a filter that directs builds to a particular -cell. The ``policy.json`` file must have a line with -``"cells_scheduler_filter:TargetCellFilter" : "is_admin:True"`` to let an admin -user specify a scheduler hint to direct a build to a particular cell. - -Optional cell configuration -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Cells store all inter-cell communication data, including user names and -passwords, in the database. Because the cells data is not updated very -frequently, use the ``[cells]cells_config`` option to specify a JSON file to -store cells data. With this configuration, the database is no longer consulted -when reloading the cells data. The file must have columns present in the Cell -model (excluding common database fields and the ``id`` column). You must -specify the queue connection information through a ``transport_url`` field, -instead of ``username``, ``password``, and so on. - -The ``transport_url`` has the following form:: - - rabbit://USERNAME:PASSWORD@HOSTNAME:PORT/VIRTUAL_HOST - -The scheme can only be ``rabbit``. - -The following sample shows this optional configuration: - -.. code-block:: json - - { - "parent": { - "name": "parent", - "api_url": "http://api.example.com:8774", - "transport_url": "rabbit://rabbit.example.com", - "weight_offset": 0.0, - "weight_scale": 1.0, - "is_parent": true - }, - "cell1": { - "name": "cell1", - "api_url": "http://api.example.com:8774", - "transport_url": "rabbit://rabbit1.example.com", - "weight_offset": 0.0, - "weight_scale": 1.0, - "is_parent": false - }, - "cell2": { - "name": "cell2", - "api_url": "http://api.example.com:8774", - "transport_url": "rabbit://rabbit2.example.com", - "weight_offset": 0.0, - "weight_scale": 1.0, - "is_parent": false - } - } diff --git a/doc/source/admin/configuration/index.rst b/doc/source/admin/configuration/index.rst index 51a3b810ef..ccd2f91e59 100644 --- a/doc/source/admin/configuration/index.rst +++ b/doc/source/admin/configuration/index.rst @@ -25,6 +25,5 @@ A list of config options based on different topics can be found below: /admin/configuration/iscsi-offload.rst /admin/configuration/hypervisors.rst /admin/configuration/schedulers.rst - /admin/configuration/cells.rst /admin/configuration/logs.rst /admin/configuration/samples/index.rst diff --git a/doc/source/admin/configuration/schedulers.rst b/doc/source/admin/configuration/schedulers.rst index 21dff34d0d..9dc080c586 100644 --- a/doc/source/admin/configuration/schedulers.rst +++ b/doc/source/admin/configuration/schedulers.rst @@ -791,35 +791,6 @@ With the API, use the ``os:scheduler_hints`` key: } } -Cell filters -~~~~~~~~~~~~ - -The following sections describe the available cell filters. - -.. note:: - - These filters are only available for cellsv1 which is deprecated. - -DifferentCellFilter -------------------- - -Schedules the instance on a different cell from a set of instances. To take -advantage of this filter, the requester must pass a scheduler hint, using -``different_cell`` as the key and a list of instance UUIDs as the value. - -ImagePropertiesFilter ---------------------- - -Filters cells based on properties defined on the instance's image. This -filter works specifying the hypervisor required in the image metadata and the -supported hypervisor version in cell capabilities. - -TargetCellFilter ----------------- - -Filters target cells. This filter works by specifying a scheduler hint of -``target_cell``. The value should be the full cell path. - .. _weights: Weights @@ -838,10 +809,7 @@ weight is given the highest priority. .. figure:: /figures/nova-weighting-hosts.png -If cells are used, cells are weighted by the scheduler in the same manner as -hosts. - -Hosts and cells are weighted based on the following options in the +Hosts are weighted based on the following options in the ``/etc/nova/nova.conf`` file: .. list-table:: Host weighting options @@ -957,43 +925,6 @@ For example: required = false weight_of_unavailable = -10000.0 -.. list-table:: Cell weighting options - :header-rows: 1 - :widths: 10, 25, 60 - - * - Section - - Option - - Description - * - [cells] - - ``mute_weight_multiplier`` - - Multiplier to weight mute children (hosts which have not sent - capacity or capacity updates for some time). - Use a negative, floating-point value. - * - [cells] - - ``offset_weight_multiplier`` - - Multiplier to weight cells, so you can specify a preferred cell. - Use a floating point value. - * - [cells] - - ``ram_weight_multiplier`` - - By default, the scheduler spreads instances across all cells evenly. - Set the ``ram_weight_multiplier`` option to a negative number if you - prefer stacking instead of spreading. Use a floating-point value. - * - [cells] - - ``scheduler_weight_classes`` - - Defaults to ``nova.cells.weights.all_weighers``, which maps to all - cell weighers included with Compute. Cells are then weighted and - sorted with the largest weight winning. - -For example: - -.. code-block:: ini - - [cells] - scheduler_weight_classes = nova.cells.weights.all_weighers - mute_weight_multiplier = -10.0 - ram_weight_multiplier = 1.0 - offset_weight_multiplier = 1.0 - Utilization aware scheduling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/source/cli/index.rst b/doc/source/cli/index.rst index 7f29b7b971..40be4005db 100644 --- a/doc/source/cli/index.rst +++ b/doc/source/cli/index.rst @@ -85,7 +85,6 @@ deployments, but are documented for existing ones. .. toctree:: :maxdepth: 1 - nova-cells nova-dhcpbridge nova-network nova-consoleauth diff --git a/doc/source/cli/nova-cells.rst b/doc/source/cli/nova-cells.rst deleted file mode 100644 index 90b6639384..0000000000 --- a/doc/source/cli/nova-cells.rst +++ /dev/null @@ -1,54 +0,0 @@ -========== -nova-cells -========== - -------------------------- -Server for the Nova Cells -------------------------- - -:Author: openstack@lists.openstack.org -:Copyright: OpenStack Foundation -:Manual section: 1 -:Manual group: cloud computing - -Synopsis -======== - -:: - - nova-cells [options] - -Description -=========== - -:program:`nova-cells` is a server daemon that serves the Nova Cells service, -which handles communication between cells and selects cells for new instances. - -.. deprecated:: 16.0.0 - Everything in this document is referring to Cells v1, which is - not recommended for new deployments and is deprecated in favor of Cells v2 - as of the 16.0.0 Pike release. For information about commands to use - with Cells v2, see the man page for :ref:`man-page-cells-v2`. - -Options -======= - -**General options** - -Files -===== - -* ``/etc/nova/nova.conf`` -* ``/etc/nova/policy.json`` -* ``/etc/nova/rootwrap.conf`` -* ``/etc/nova/rootwrap.d/`` - -See Also -======== - -* :nova-doc:`OpenStack Nova <>` - -Bugs -==== - -* Nova bugs are managed at `Launchpad `__ diff --git a/doc/source/conf.py b/doc/source/conf.py index 35517f9a6d..12d28deb66 100644 --- a/doc/source/conf.py +++ b/doc/source/conf.py @@ -120,7 +120,6 @@ _man_pages = [ ('nova-api-metadata', u'Cloud controller fabric'), ('nova-api-os-compute', u'Cloud controller fabric'), ('nova-api', u'Cloud controller fabric'), - ('nova-cells', u'Cloud controller fabric'), ('nova-compute', u'Cloud controller fabric'), ('nova-console', u'Cloud controller fabric'), ('nova-consoleauth', u'Cloud controller fabric'), diff --git a/doc/source/reference/index.rst b/doc/source/reference/index.rst index 7f023ff3a6..6731b8c069 100644 --- a/doc/source/reference/index.rst +++ b/doc/source/reference/index.rst @@ -46,7 +46,7 @@ these documents will move into the "Internals" section. If you want to get involved in shaping the future of nova's architecture, these are a great place to start reading up on the current plans. -* :doc:`/user/cells`: Comparison of Cells v1 and v2, and how v2 is evolving +* :doc:`/user/cells`: How cells v2 is evolving * :doc:`/reference/policy-enforcement`: How we want policy checks on API actions to work in the future * :doc:`/reference/stable-api`: What stable api means to nova diff --git a/doc/source/user/cells.rst b/doc/source/user/cells.rst index 7e79d47fff..362493bc63 100644 --- a/doc/source/user/cells.rst +++ b/doc/source/user/cells.rst @@ -22,59 +22,6 @@ Andrew Laski gave at the Austin (Newton) summit which is worth watching. .. _presentation: https://www.openstack.org/videos/summits/austin-2016/nova-cells-v2-whats-going-on -Cells V1 -======== - -Historically, Nova has depended on a single logical database and message queue -that all nodes depend on for communication and data persistence. This becomes -an issue for deployers as scaling and providing fault tolerance for these -systems is difficult. - -We have an experimental feature in Nova called "cells", hereafter referred to -as "cells v1", which is used by some large deployments to partition compute -nodes into smaller groups, coupled with a database and queue. This seems to be -a well-liked and easy-to-understand arrangement of resources, but the -implementation of it has issues for maintenance and correctness. -See `Comparison with Cells V1`_ for more detail. - -Status -~~~~~~ - -.. deprecated:: 16.0.0 - Cells v1 is deprecated in favor of Cells v2 as of the 16.0.0 Pike release. - -Cells v1 is considered experimental and receives much less testing than the -rest of Nova. For example, there is no job for testing cells v1 with Neutron. - -The priority for the core team is implementation of and migration to cells v2. -Because of this, there are a few restrictions placed on cells v1: - -#. Cells v1 is in feature freeze. This means no new feature proposals for cells - v1 will be accepted by the core team, which includes but is not limited to - API parity, e.g. supporting virtual interface attach/detach with Neutron. -#. Latent bugs caused by the cells v1 design will not be fixed, e.g. - `bug 1489581 `_. So if new - tests are added to Tempest which trigger a latent bug in cells v1 it may not - be fixed. However, regressions in working function should be tracked with - bugs and fixed. -#. Changes proposed to nova will not be automatically tested against a Cells v1 - environment. To manually trigger Cells v1 integration testing on a nova - change in Gerrit, leave a review comment of "check experimental" and the - *nova-cells-v1* job will run on it, but the job is non-voting, meaning if - it fails it will not prevent the patch from being merged if approved by the - core team. - -**Suffice it to say, new deployments of cells v1 are not encouraged.** - -The restrictions above are basically meant to prioritize effort and focus on -getting cells v2 completed, and feature requests and hard to fix latent bugs -detract from that effort. Further discussion on this can be found in the -`2015/11/12 Nova meeting minutes -`_. - -There are no plans to remove Cells V1 until V2 is usable by existing -deployments and there is a migration path. - .. _cells-v2: Cells V2 @@ -165,23 +112,6 @@ The benefits of this new organization are: * Adding new sets of hosts as a new "cell" allows them to be plugged into a deployment and tested before allowing builds to be scheduled to them. -Comparison with Cells V1 ------------------------- - -In reality, the proposed organization is nearly the same as what we currently -have in cells today. A cell mostly consists of a database, queue, and set of -compute nodes. The primary difference is that current cells require a -nova-cells service that synchronizes information up and down from the top level -to the child cell. Additionally, there are alternate code paths in -compute/api.py which handle routing messages to cells instead of directly down -to a compute host. Both of these differences are relevant to why we have a hard -time achieving feature and test parity with regular nova (because many things -take an alternate path with cells) and why it's hard to understand what is -going on (all the extra synchronization of data). The new proposed cellsv2 -organization avoids both of these problems by letting things live where they -should, teaching nova to natively find the right db, queue, and compute node to -handle a given request. - Database split ~~~~~~~~~~~~~~ @@ -572,6 +502,9 @@ database. This will set up a single cell Nova deployment. Upgrade with Cells V1 ~~~~~~~~~~~~~~~~~~~~~ +.. todo:: This needs to be removed but `Adding a new cell to an existing deployment`_ + is still using it. + You are upgrading an existing Nova install that has Cells V1 enabled and have compute hosts in your databases. This will set up a multiple cell Nova deployment. At this time, it is recommended to keep Cells V1 enabled during and diff --git a/doc/source/user/cellsv2-layout.rst b/doc/source/user/cellsv2-layout.rst index a9fb175aac..ae45a225e2 100644 --- a/doc/source/user/cellsv2-layout.rst +++ b/doc/source/user/cellsv2-layout.rst @@ -22,12 +22,6 @@ is geared towards people who want to have multiple cells for whatever reason, the nature of the cellsv2 support in Nova means that it applies in some way to all deployments. -.. note:: The concepts laid out in this document do not in any way - relate to CellsV1, which includes the ``nova-cells`` - service, and the ``[cells]`` section of the configuration - file. For more information on the differences, see the main - :ref:`cells` page. - Concepts ======== diff --git a/doc/source/user/upgrade.rst b/doc/source/user/upgrade.rst index 15fe8c259e..d7e0124813 100644 --- a/doc/source/user/upgrade.rst +++ b/doc/source/user/upgrade.rst @@ -279,10 +279,6 @@ RPC version pinning .. note:: - This does not apply to cells v1 deployments since cells v1 does not - support rolling upgrades. It is assumed that cells v1 deployments are - upgraded in lockstep so n-1 cells compatibility does not work. - The procedure for rolling upgrades with multiple cells v2 cells is not yet determined. diff --git a/doc/test/redirect-tests.txt b/doc/test/redirect-tests.txt index 0d761888db..780df9ffc8 100644 --- a/doc/test/redirect-tests.txt +++ b/doc/test/redirect-tests.txt @@ -27,8 +27,8 @@ /nova/latest/man/nova-api-metadata.html 301 /nova/latest/cli/nova-api-metadata.html /nova/latest/man/nova-api-os-compute.html 301 /nova/latest/cli/nova-api-os-compute.html /nova/latest/man/nova-api.html 301 /nova/latest/cli/nova-api.html -/nova/latest/man/nova-cells.html 301 /nova/latest/cli/nova-cells.html # this is gone and never coming back, indicate that to the end users +/nova/latest/man/nova-cells.html 301 /nova/latest/cli/nova-cells.html /nova/latest/man/nova-compute.html 301 /nova/latest/cli/nova-compute.html /nova/latest/man/nova-conductor.html 301 /nova/latest/cli/nova-conductor.html /nova/latest/man/nova-console.html 301 /nova/latest/cli/nova-console.html