Difference between revisions of "Nova-Cells-v2"
(→TODOs) |
(→Bugs) |
||
Line 13: | Line 13: | ||
* https://bugs.launchpad.net/nova/+bug/1656675 - There is no way to list cell mappings besides looking into the DB | * 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/ | ** 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 | ||
=== TODOs === | === TODOs === |
Revision as of 19:53, 15 January 2017
Contents
Nova Cells v2
Bugs
- https://bugs.launchpad.net/nova/+bug/1656276 - Error running nova-manage cell_v2 simple_cell_setup when configuring nova with puppet-nova
- The create_cell CLI should go toward fixing this: https://review.openstack.org/#/c/332713/
- https://bugs.launchpad.net/nova/+bug/1649341 - Undercloud upgrade fails with "Cell mappings are not created, but required for Ocata"
- Fixed on master in Nova, backport proposed to stable/newton. However, this change caused issues for TripleO on master which is bug 1656276 above.
- 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/
- 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
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/
- 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)
- 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.
- We'd have to figure out in what cases can you not delete the cell mapping, i.e. can you only delete an 'empty' cell mapping? Or can you force delete a cell mapping along with it's host mappings? I'd think that in the initial implementation of the command we'd only allow deleting an empty cell.
- Integrate the 'nova-status upgrade check' CLI into the CI/QA system (grenade).
- 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
- https://review.openstack.org/#/q/topic:bp/cells-scheduling-interaction
- Otherwise see the cells v2 section in the Ocata review priorities etherpad: https://etherpad.openstack.org/p/ocata-nova-priorities-tracking
References
- Note the original cells wiki is here: https://wiki.openstack.org/wiki/Blueprint-nova-compute-cells
- Kilo design summit etherpad: https://etherpad.openstack.org/p/kilo-nova-cells
- nova-specs: https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+branch:master+topic:bp/cells-instance-mapping,n,z
- Flow diagrams: http://paste.openstack.org/show/144068/
- https://etherpad.openstack.org/p/nova-cells-flow-diagram commentable version