From 8d2c015f0a0493e8449c071aa602d6e309314403 Mon Sep 17 00:00:00 2001 From: Matt Riedemann Date: Thu, 17 Mar 2016 13:56:01 -0400 Subject: [PATCH] Re-propose scheduling interaction for cells This was partially implemented in Mitaka, re-proposed for Newton to continue the work. Previously-approved: Mitaka Spec for blueprint cells-scheduling-interaction Change-Id: Icc0d0cdaefc46f56408d22a10adc6afec7163dee --- .../approved/cells-scheduling-interaction.rst | 175 ++++++++++++++++++ 1 file changed, 175 insertions(+) create mode 100644 specs/newton/approved/cells-scheduling-interaction.rst diff --git a/specs/newton/approved/cells-scheduling-interaction.rst b/specs/newton/approved/cells-scheduling-interaction.rst new file mode 100644 index 000000000..dbd4f12a2 --- /dev/null +++ b/specs/newton/approved/cells-scheduling-interaction.rst @@ -0,0 +1,175 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +================================ +Scheduling interaction for cells +================================ + +https://blueprints.launchpad.net/nova/+spec/cells-scheduling-interaction + +In order to schedule instance builds to compute hosts Nova and the scheduler +will need to take into account that hosts are grouped into cells. It is not +necessary that this is apparent when Nova is requesting a placement decision. + + +Problem description +=================== + +In order to partition Nova into cells the scheduler will need to be involved +earlier in the build process. + +Use Cases +---------- + +* Operators want to partition their deployments into cells for scaling, failure + domain, and buildout reasons. When partitioned, we need to have flexible + scheduling that can make decisions on cells and hosts. + + +Proposed change +=============== + +The scheduler will be queried at the api level so that it knows which cell to +pass the build to. The instance table exists in a cell and not in the api +database, so to create an instance we will first need to know which cell to +create it in. + +The scheduler will continue to return a (host, node) tuple and the calling +service will look up the host in a mapping table to determine which cell it is +in. This means the current select_destinations interface will not need to +change. Querying the scheduler will take place after the API has returned a +response so the most reasonable thing to do is pass the build request to a +conductor operating outside of any cell. The conductor will call the scheduler +and then create the instance in the cell and pass the build request to it. + +Rescheduling will still take place within a cell via the normal +compute->conductor loop, using the conductors within the cell. Adding +rescheduling at a cell level will be a later effort. + +Information about cells will need to be fed into the scheduler in order for it +to account for that during its placement decisions, but that is outside the +scope of this spec. + + +Alternatives +------------ + +We could query the scheduler at two points like in cellsv1. This creates more +deployment complexity and creates an unnecessary coupling between the +architecture of Nova and the scheduler. + +Data model impact +----------------- + +None + +REST API impact +--------------- + +None + +Security impact +--------------- + +None + +Notifications impact +-------------------- + +None + +Other end user impact +--------------------- + +None + +Performance Impact +------------------ + +None + +Other deployer impact +--------------------- + +Nova-conductor will need to be deployed for use by nova-api. + +Developer impact +---------------- + +None + + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + alaski + +Other contributors: + None + +Work Items +---------- + +* Add a conductor method to call the scheduler and then handle the latter half + of what the api currently does for a build request(create instance in db and + cast to the cell conductor). + +* Update the conductor build_instances interface to take a scheduling decision + and not call the scheduler if it's provided. This allows for bypassing + scheduling when it comes from the api conductor but still call the scheduler + when a compute requests a reschedule. + +* Update devstack to spin up a conductor for use by the nova-api service. + + +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 will be written describing the flow of an instance build and how +and where scheduling decisions are made. + + +References +========== + +``https://etherpad.openstack.org/p/kilo-nova-cells`` +``https://etherpad.openstack.org/p/nova-cells-scheduling-requirements`` + + +History +======= + +.. list-table:: Revisions + :header-rows: 1 + + * - Release Name + - Description + * - Liberty + - Introduced + * - Mitaka + - Re-proposed; partially implemented. + * - Newton + - Re-proposed.