Jump to: navigation, search

Difference between revisions of "Nova-Cells-v2"

(TODOs)
(Nova Cells v2)
Line 9: Line 9:
 
* https://bugs.launchpad.net/nova/+bug/1656017 - nova-manage cell_v2 map_cell0 always returns a non-0 exit code
 
* https://bugs.launchpad.net/nova/+bug/1656017 - nova-manage cell_v2 map_cell0 always returns a non-0 exit code
 
** dtp has a fix here: https://review.openstack.org/#/c/420132/
 
** dtp has a fix here: https://review.openstack.org/#/c/420132/
* https://bugs.launchpad.net/nova/+bug/1656673 - map_cell0 should use the main DB connection, not the API DB
 
** dansmith has a fix here: https://review.openstack.org/#/c/420439/
 
* https://bugs.launchpad.net/nova/+bug/1656675 - There is no way to list cell mappings besides looking into the DB
 
** mriedem has a fix here: https://review.openstack.org/#/c/420440/
 
* https://bugs.launchpad.net/nova/+bug/1656691 - There is no way to delete a cell mapping except via DB directly
 
** mriedem has a fix here: https://review.openstack.org/#/c/420451/
 
  
 
=== TODOs ===
 
=== TODOs ===
  
 
* The deployment/upgrade process needs to be documented in more than just the release notes.
 
* The deployment/upgrade process needs to be documented in more than just the release notes.
** dansmith has a start on the docs here: https://review.openstack.org/#/c/420198/
+
** dansmith has a start on the docs here: https://review.openstack.org/#/c/420198/ (merged)
 
** (diana will take this) On a side note, we should also have man pages for the cell_v2 commands because there is confusion around the inputs and outputs and how return codes should be treated, i.e. is 1 an error or not? Put the CLI docs here: http://docs.openstack.org/developer/nova/man/nova-manage.html
 
** (diana will take this) On a side note, we should also have man pages for the cell_v2 commands because there is confusion around the inputs and outputs and how return codes should be treated, i.e. is 1 an error or not? Put the CLI docs here: http://docs.openstack.org/developer/nova/man/nova-manage.html
 
*** Reviews for those docs: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:man
 
*** Reviews for those docs: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:man
Line 29: Line 23:
 
*** map_cell_and_hosts: creates a cell mapping and associates hosts with it (requires unmapped compute hosts registered already)
 
*** map_cell_and_hosts: creates a cell mapping and associates hosts with it (requires unmapped compute hosts registered already)
 
*** discover_hosts: associates unmapped hosts with an existing cell mapping (or all cell mappings if a specific cell isn't specified)
 
*** discover_hosts: associates unmapped hosts with an existing cell mapping (or all cell mappings if a specific cell isn't specified)
** Commands TODO?:
 
*** create_cell: creates a cell mapping intended for association with hosts later via discover_hosts: https://review.openstack.org/#/c/332713/
 
*** list_cells: list current cell mappings, noting any that are empty (to help with 1. knowing whether a cell needs to be created 2. finding empty cells for use or for cleanup): https://review.openstack.org/420440
 
*** delete_cell: delete a cell mapping, for use in cleaning up erroneously created cell mappings or wrong cell mappings, etc: https://review.openstack.org/#/c/420451/
 
 
* Integrate the 'nova-status upgrade check' CLI into the CI/QA system (grenade).
 
* Integrate the 'nova-status upgrade check' CLI into the CI/QA system (grenade).
 +
* mriedem is working on setting up multiple cells in the multinode job: https://review.openstack.org/#/c/420976/
 +
** That's probably going to cause issues for the live migration tests since we can't migrate between cells and we only have two computes in that job, and with my change each is in a cell.
 +
** sdague also pointed out some design issues in the dependent change which means needing to callback into devstack from devstack-gate at the end of the deploy to run discover_hosts.
 
* Older tracking etherpads (these may be out of date):
 
* Older tracking etherpads (these may be out of date):
 
** https://etherpad.openstack.org/p/cellsV2-remaining-work-items
 
** https://etherpad.openstack.org/p/cellsV2-remaining-work-items

Revision as of 23:37, 18 January 2017

Nova Cells v2

Bugs

TODOs

  • The deployment/upgrade process needs to be documented in more than just the release notes.
    • dansmith has a start on the docs here: https://review.openstack.org/#/c/420198/ (merged)
    • (diana will take this) On a side note, we should also have man pages for the cell_v2 commands because there is confusion around the inputs and outputs and how return codes should be treated, i.e. is 1 an error or not? Put the CLI docs here: http://docs.openstack.org/developer/nova/man/nova-manage.html
    • alaski's older docs patch (which is probably out of date now but might be useful) is here: https://review.openstack.org/#/c/267153/
    • Summary of current commands:
      • map_cell0: creates a cell mapping for cell0
      • simple_cell_setup: creates a cell mapping for cell0 and creates a cell mapping and associates hosts with it (requires unmapped compute hosts registered already). Intended as a lightweight way for non-cells-v1 users to setup cells v2 during an upgrade.
      • map_cell_and_hosts: creates a cell mapping and associates hosts with it (requires unmapped compute hosts registered already)
      • discover_hosts: associates unmapped hosts with an existing cell mapping (or all cell mappings if a specific cell isn't specified)
  • Integrate the 'nova-status upgrade check' CLI into the CI/QA system (grenade).
  • mriedem is working on setting up multiple cells in the multinode job: https://review.openstack.org/#/c/420976/
    • That's probably going to cause issues for the live migration tests since we can't migrate between cells and we only have two computes in that job, and with my change each is in a cell.
    • sdague also pointed out some design issues in the dependent change which means needing to callback into devstack from devstack-gate at the end of the deploy to run discover_hosts.
  • Older tracking etherpads (these may be out of date):

Open Questions

  • Should the computes self-register with a cell when the compute_nodes record is created from the ResourceTracker? https://review.openstack.org/#/c/369634/
    • How would the computes know which cell to map to? We could add something to the model to flag a 'default' or 'staging' cell mapping, or put something into nova.conf on the compute node.
    • If we auto-register into a default/staging cell, how do we move hosts to other cells? nova-manage CLI?
  • Why can't we create an empty cell, i.e. a cell mapping with no computes? This is a fresh-install scenario.
    • Note that the nova-status upgrade check command does not consider it a failure if there are cell mappings but no compute nodes yet but simple_cell_setup does consider that a failure, see bug 1656276.
    • There has been a review up for this for awhile: https://review.openstack.org/#/c/332713/
      • This way, a fresh install would do something like: 'nova-manage cell_v2 map_cell0' 'nova-manage cell_v2 create_cell' and then once compute hosts are available, operator runs 'nova-manage cell_v2 discover_hosts'

Manifesto

http://docs.openstack.org/developer/nova/cells.html#manifesto

Testing

https://etherpad.openstack.org/p/nova-cells-testing

DB Table Analysis

https://etherpad.openstack.org/p/nova-cells-table-analysis

Scheduling requirements

https://etherpad.openstack.org/p/nova-cells-scheduling-requirements

Code Review

References