<div dir="ltr">Thanks Dan and Matt!</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 19, 2017 at 2:48 PM, 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">FYI<div><div class="h5"><br>
<br>
<br>
-------- Forwarded Message --------<br>
Subject: [openstack-dev] [nova] Boston Forum session recap - cellsv2<br>
Date: Fri, 19 May 2017 08:13:24 -0700<br>
From: Dan Smith <<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>><br>
Reply-To: OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack<wbr>.org</a>><br>
To: OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack<wbr>.org</a>><br>
<br>
The etherpad for this session is here [1]. The goal of the session was<br>
to get some questions answered that the developers had for operators<br>
around the topic of cellsv2.<br>
<br>
The bulk of the time was spent discussing ways to limit instance<br>
scheduling retries in a cellsv2 world where placement eliminates<br>
resource-reservation races. Reschedules would be upcalls from the cell,<br>
which we are trying to avoid.<br>
<br>
While placement should eliminate 95% (or more) of reschedules due to<br>
pre-claiming resources before booting, there will still be cases where<br>
we may want to reschedule due to unexpected transient failures. How many<br>
of those remain, and whether or not rescheduling for them is really<br>
useful is in question.<br>
<br>
The compromise that seemed popular in the room was to grab more than one<br>
host at the time of scheduling, claim for that one, but pass the rest to<br>
the cell. If the cell needs to reschedule, the cell conductor would try<br>
one of the alternates that came as part of the original boot request,<br>
instead of asking scheduler again.<br>
<br>
During the discussion of this, an operator raised the concern that<br>
without reschedules, a single compute that fails to boot 100% of the<br>
time ends up becoming a magnet for all future builds, looking like an<br>
excellent target for the scheduler, but failing anything that is sent to<br>
it. If we don't reschedule, that situation could be very problematic. An<br>
idea came out that we should really have compute monitor and disable<br>
itself if a certain number of _consecutive_ build failures crosses a<br>
threshold. That would mitigate/eliminate the "fail magnet" behavior and<br>
further reduce the need for retries. A patch has been proposed for this,<br>
and so far enjoys wide support [2].<br>
<br>
We also discussed the transition to counting quotas, and what that means<br>
for operators. The room seemed in favor of this, and discussion was brief.<br>
<br>
Finally, I made the call for people with reasonably-sized pre-prod<br>
environments to begin testing cellsv2 to help prove it out and find the<br>
gremlins. CERN and NeCTAR specifically volunteered for this effort.<br>
<br>
[1]<br>
<a href="https://etherpad.openstack.org/p/BOS-forum-cellsv2-developer-community-coordination" rel="noreferrer" target="_blank">https://etherpad.openstack.org<wbr>/p/BOS-forum-cellsv2-developer<wbr>-community-coordination</a><br>
[2] <a href="https://review.openstack.org/#/c/463597/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/463597/</a><br>
<br>
--Dan<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>
<br></div></div>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
</blockquote></div><br></div>