Cells: Add host mapping table and object
In order to properly route RPC messages or database updates to the proper cell when given just a host we need a mapping of host to cell. We will be provided only a host by the scheduler or for Host API requests. Change-Id: Ifd37410ea0009d2ee8a5720461377bef6e83eb18
This commit is contained in:
Andrew Laski
173
specs/liberty/approved/cells-host-mapping.rst
Normal file
173
specs/liberty/approved/cells-host-mapping.rst
Normal file
@@ -0,0 +1,173 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==================
|
||||
Cells host mapping
|
||||
==================
|
||||
|
||||
https://blueprints.launchpad.net/nova/+spec/cells-host-mapping
|
||||
|
||||
Since the scheduler will return a host rather than a cell we need to know which
|
||||
cell that host is in. A new table will be created which can store this
|
||||
mapping.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
When Nova is partitioned into cells, the compute api needs to know which cell
|
||||
to communicate with in order to build a scheduled instance, or for host API
|
||||
requests. There is currently no mapping of host to cell so given just a host
|
||||
there is no way to know how to pass information to that host.
|
||||
|
||||
Use Cases
|
||||
----------
|
||||
|
||||
* Operators want to partition their deployments into cells for scaling, failure
|
||||
domain, and buildout reasons. When partitioned, we need a lookup table to
|
||||
know which partition a host is in.
|
||||
|
||||
Project Priority
|
||||
-----------------
|
||||
|
||||
Priorities have not been decided for Liberty.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
The change being proposed is a new table in the 'nova_api' database for storing
|
||||
a mapping of host to cell and an object to interact with it. Migration of data
|
||||
into this table will be tackled in a separate spec.
|
||||
|
||||
The following diagram may help visualize it.::
|
||||
|
||||
api/cell boundary
|
||||
scheduler returns a host |
|
||||
| |
|
||||
v |
|
||||
nova-api+--------------------------->cell-db/rpc
|
||||
+ |
|
||||
+----+ |
|
||||
| |
|
||||
v |
|
||||
host_mapping (joined with) cell_mapping |
|
||||
|
||||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
We could continue to use the nova-cells model in place today.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
A new 'host_mapping' table will be added to the 'nova_api' database.
|
||||
|
||||
The table will look like:::
|
||||
|
||||
CREATE TABLE `host_mapping` (
|
||||
`created_at` datetime DEFAULT NULL,
|
||||
`updated_at` datetime DEFAULT NULL,
|
||||
`id` int(11) NOT NULL AUTO_INCREMENT,
|
||||
`host` varchar(255) NOT NULL,
|
||||
`cell_uuid` varchar(36) NOT NULL)
|
||||
|
||||
And host will be an indexed column. Other indexes are possible as well
|
||||
and can be discussed in the code review.
|
||||
|
||||
It should be noted that there is no 'deleted' or 'deleted_at' column here. If
|
||||
a host exists it should be mapped, it should only be deleted if the host is
|
||||
being permanently removed in which case there is no reason to keep it here.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
On its own this change does not introduce a performance impact. When it's used
|
||||
by later specs it does introduce another database lookup for some actions
|
||||
within Nova.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
This introduces a new table into the 'nova_api' database. And as described in
|
||||
the "Data model impact" section above it should be considered when running any
|
||||
cleanup of hosts. If hosts are removed from a deployment they can be removed
|
||||
from the host_mapping table as well.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
alaski
|
||||
|
||||
Other contributors:
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Add database migration for 'host_mapping' table.
|
||||
|
||||
* Add HostMapping object.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Since this is designed to be an internal re-architecting of Nova with no user
|
||||
visible changes the current suite of Tempest or functional tests should
|
||||
suffice. At some point we will want to look at how to test multiple cells or
|
||||
potentially exposing the concept of a cell in the API and we will tackle
|
||||
testing requirements then.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Documentation should be added about the new table and what its usage will be.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
``https://etherpad.openstack.org/p/kilo-nova-cells``
|
||||
Reference in New Issue
Block a user