Open Stack

We talked about cells on Wednesday morning at the PTG. The full etherpad 
is here [1].

Searchlight integration
-----------------------

We talked a bit about what needs to happen for this, and it starts with 
getting the data into searchlight so that it can serve the REST API, 
which is being worked in this blueprint [2]. We want to get that done 
early in Pike.

We plan on making the use of Searchlight configurable in Nova since at 
first you might not even have anything in it, so listing instances 
wouldn't work. We're also going to attempt to merge-sort when listing 
instances across multiple cells but it's going to be a known issue that 
it will be slow.

For testing Nova with Searchlight, we need to start by enabling the 
Searchlight devstack plugin in the nova-next CI job, which I'll work on.

I'm going to talk to Kevin Zheng about seeing if he can spend some time 
on getting Nova to use Searchlight if it's (1) configured for use and 
(2) is available (the endpoint is in the service catalog). Kevin is a 
Searchlight core and familiar with the Nova API code, so he's a good 
candidate for working on this (assuming he's available and willing to 
own it).

Cells-aware gaps in the API
---------------------------

Dan Smith has started a blueprint [3] for closing gaps in the API which 
break in a multi-cell deployment. He has a test patch [4] to expose the 
failures and then they can be worked on individually. The pattern of the 
work is in [5]. Help is welcome here, so please attend the weekly cells 
meeting [6] if you want to help out.

Auto-discovery of compute hosts
-------------------------------

The "discover_hosts_in_cells_interval" config option was introduced in 
Ocata which controls a periodic task in the scheduler to discover new 
unmapped compute hosts but it's not very efficient since it queries all 
cell mappings and then all compute nodes in each cell mapping and checks 
to see if those compute nodes are yet mapped to the cell in the nova_api 
database. Dan Smith has a series of changes [7] which should make that 
discovery process more efficient, it just needs to be cleaned up a bit.

Service arrangement
-------------------

Dan Smith is working on a series of changes in both Nova and devstack 
for testing with multiple cells [8]. The general idea is that there will 
still be two nodes and two nova-compute services. There will be three 
nova-conductor services, one per cell, and then another top-level "super 
conductor" which is there for building instances and sending the server 
create down to one of the cells. All three conductors are going to be 
running in the subnode just to balance the resources a bit otherwise the 
primary node is going to be starved. The multi-cell job won't be running 
migration tests since we don't currently support instance move 
operations between cells. We're going to work a hack into the scheduler 
to restrict a move operation to the same cell the instance is already 
in. This means the live migration job will still be a single-cell setup 
where both nova-computes are in the same cell.

Getting rid of nova-consoleauth
-------------------------------

There is an unfinished blueprint [9] from Paul Murray which melwitt is 
going to pick up for Pike. The idea is to move the tokens into the 
database so we don't care where the consoleauth service lives and then 
we can also kill the service.

[1] https://etherpad.openstack.org/p/nova-ptg-pike-cells
[2] 
https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight
[3] https://blueprints.launchpad.net/nova/+spec/cells-aware-api
[4] https://review.openstack.org/#/c/433318/
[5] https://review.openstack.org/#/c/433362/
[6] http://eavesdrop.openstack.org/#Nova_Cellsv2_Meeting
[7] https://review.openstack.org/#/c/427901/
[8] https://review.openstack.org/#/c/436094/
[9] https://blueprints.launchpad.net/nova/+spec/convert-consoles-to-objects

-- 

Thanks,

Matt Riedemann