Skip to content
Snippets Groups Projects
  • Doug Szumski's avatar
    78a828ef
    Support multiple nova cells · 78a828ef
    Doug Szumski authored
    
    This patch adds initial support for deploying multiple Nova cells.
    
    Splitting a nova-cell role out from the Nova role allows a more granular
    approach to deploying and configuring Nova services.
    
    A new enable_cells flag has been added that enables the support of
    multiple cells via the introduction of a super conductor in addition to
    cell-specific conductors. When this flag is not set (the default), nova
    is configured in the same manner as before - with a single conductor.
    
    The nova role now deploys the global services:
    
    * nova-api
    * nova-scheduler
    * nova-super-conductor (if enable_cells is true)
    
    The nova-cell role handles services specific to a cell:
    
    * nova-compute
    * nova-compute-ironic
    * nova-conductor
    * nova-libvirt
    * nova-novncproxy
    * nova-serialproxy
    * nova-spicehtml5proxy
    * nova-ssh
    
    This patch does not support using a single cell controller for managing
    more than one cell. Support for sharing a cell controller will be added
    in a future patch.
    
    This patch should be backwards compatible and is tested by existing CI
    jobs. A new CI job has been added that tests a multi-cell environment.
    
    ceph-mon has been removed from the play hosts list as it is not
    necessary - delegate_to does not require the host to be in the play.
    
    Documentation will be added in a separate patch.
    
    Partially Implements: blueprint support-nova-cells
    Co-Authored-By: default avatarMark Goddard <mark@stackhpc.com>
    Change-Id: I810aad7d49db3f5a7fd9a2f0f746fd912fe03917
    78a828ef
    History
    Support multiple nova cells
    Doug Szumski authored
    
    This patch adds initial support for deploying multiple Nova cells.
    
    Splitting a nova-cell role out from the Nova role allows a more granular
    approach to deploying and configuring Nova services.
    
    A new enable_cells flag has been added that enables the support of
    multiple cells via the introduction of a super conductor in addition to
    cell-specific conductors. When this flag is not set (the default), nova
    is configured in the same manner as before - with a single conductor.
    
    The nova role now deploys the global services:
    
    * nova-api
    * nova-scheduler
    * nova-super-conductor (if enable_cells is true)
    
    The nova-cell role handles services specific to a cell:
    
    * nova-compute
    * nova-compute-ironic
    * nova-conductor
    * nova-libvirt
    * nova-novncproxy
    * nova-serialproxy
    * nova-spicehtml5proxy
    * nova-ssh
    
    This patch does not support using a single cell controller for managing
    more than one cell. Support for sharing a cell controller will be added
    in a future patch.
    
    This patch should be backwards compatible and is tested by existing CI
    jobs. A new CI job has been added that tests a multi-cell environment.
    
    ceph-mon has been removed from the play hosts list as it is not
    necessary - delegate_to does not require the host to be in the play.
    
    Documentation will be added in a separate patch.
    
    Partially Implements: blueprint support-nova-cells
    Co-Authored-By: default avatarMark Goddard <mark@stackhpc.com>
    Change-Id: I810aad7d49db3f5a7fd9a2f0f746fd912fe03917
nova.yml 6.64 KiB
---
# This playbook is for nova services. Due to support for deployment of cells,
# nova is separated into two roles - nova and nova-cell. This makes it more
# complicated than other services, as we may execute each role several times
# for a given operation.
#
# The nova role now deploys the global services:
#
# * nova-api
# * nova-scheduler
# * nova-super-conductor (if enable_cells is true)
#
# The nova-cell role handles services specific to a cell:
#
# * nova-compute
# * nova-compute-ironic
# * nova-conductor
# * nova-libvirt
# * nova-novncproxy
# * nova-serialproxy
# * nova-spicehtml5proxy
# * nova-ssh

# We need to perform database bootstrapping before deploying or upgrading any
# containers, to ensure all database schema migrations have been performed,
# both in the API and cell databases. Note that this should not be disruptive
# to the Nova services, which will continue to run against the new schema.

- name: Bootstrap nova API databases
  gather_facts: false
  hosts:
    - nova-api
    - '&enable_nova_True'
  tags:
    - nova
    - nova-bootstrap
    - nova-api
    - nova-api-bootstrap
  serial: '{{ kolla_serial|default("0") }}'
  tasks:
    # * Create nova API & cell0 DBs & users
    # * API DB schema migrations
    # * Map cell0
    # * Cell0 DB schema migrations
    - name: Bootstrap deploy
      include_role:
        name: nova
        tasks_from: bootstrap
      when:
        - enable_nova | bool
        - kolla_action in ['deploy', 'reconfigure']

    # * API DB schema migrations
    # * Cell0 DB schema migrations
    - name: Bootstrap upgrade
      include_role:
        name: nova
        tasks_from: bootstrap_upgrade
      when:
        - enable_nova | bool
        - kolla_action == 'upgrade'

- name: Bootstrap nova cell databases
  gather_facts: false
  hosts:
    - nova-conductor
    - '&enable_nova_True'
  tags:
    - nova
    - nova-bootstrap