<div dir="ltr">Matt,<div><br></div><div>Thanks for the recap, it's a pity I cannot attend PTG due to personal reason, I will be willing to take the work you mentioned, and will check the details with you.</div><div><br></div><div>And another thing, I don't know whether you guys discussed or not, I saw in [1] we are talking about adding tags field(and others of cause) to the instance notification</div><div>payload, to be able to send during instance.create and instance.update. The fact is that currently we cannot add tags during boot, nor we send notifications when we</div><div>add/update/delete tags latter(it is a direct DB change and no instance.update notification has been sent out), so for tags field, we have to wait for another instance.update</div><div>action to get the latest info. And I have already tried to working on the boot thing[2] and already planned to work on the tag notification thing[3].</div><div><br></div><div>So, are there any plans about those? Maybe it is OK to send out instance.update notification in tags actions once [1] got merged?</div><div><br></div><div>Thanks,</div><div><br></div><div>Kevin Zheng</div><div><br></div><div>[1] <a href="https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight" rel="noreferrer" target="_blank" style="font-size:12.8px">https://blueprints.launchpad.n<wbr>et/nova/+spec/additional-notif<wbr>ication-fields-for-searchlight</a></div><div>[2] <a href="https://blueprints.launchpad.net/nova/+spec/support-tag-instance-when-boot">https://blueprints.launchpad.net/nova/+spec/support-tag-instance-when-boot</a></div><div>[3] <a href="https://blueprints.launchpad.net/nova/+spec/send-tag-notification">https://blueprints.launchpad.net/nova/+spec/send-tag-notification</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 28, 2017 at 6:33 AM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We talked about cells on Wednesday morning at the PTG. The full etherpad is here [1].<br>
<br>
Searchlight integration<br>
-----------------------<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
Cells-aware gaps in the API<br>
---------------------------<br>
<br>
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.<br>
<br>
Auto-discovery of compute hosts<br>
------------------------------<wbr>-<br>
<br>
The "discover_hosts_in_cells_inter<wbr>val" 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.<br>
<br>
Service arrangement<br>
-------------------<br>
<br>
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.<br>
<br>
Getting rid of nova-consoleauth<br>
------------------------------<wbr>-<br>
<br>
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.<br>
<br>
[1] <a href="https://etherpad.openstack.org/p/nova-ptg-pike-cells" rel="noreferrer" target="_blank">https://etherpad.openstack.org<wbr>/p/nova-ptg-pike-cells</a><br>
[2] <a href="https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight" rel="noreferrer" target="_blank">https://blueprints.launchpad.n<wbr>et/nova/+spec/additional-notif<wbr>ication-fields-for-searchlight</a><br>
[3] <a href="https://blueprints.launchpad.net/nova/+spec/cells-aware-api" rel="noreferrer" target="_blank">https://blueprints.launchpad.n<wbr>et/nova/+spec/cells-aware-api</a><br>
[4] <a href="https://review.openstack.org/#/c/433318/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/433318/</a><br>
[5] <a href="https://review.openstack.org/#/c/433362/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/433362/</a><br>
[6] <a href="http://eavesdrop.openstack.org/#Nova_Cellsv2_Meeting" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org<wbr>/#Nova_Cellsv2_Meeting</a><br>
[7] <a href="https://review.openstack.org/#/c/427901/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/427901/</a><br>
[8] <a href="https://review.openstack.org/#/c/436094/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/436094/</a><br>
[9] <a href="https://blueprints.launchpad.net/nova/+spec/convert-consoles-to-objects" rel="noreferrer" target="_blank">https://blueprints.launchpad.n<wbr>et/nova/+spec/convert-consoles<wbr>-to-objects</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</font></span></blockquote></div><br></div>