<tt><font size=2>> From: Thomas Thrainer <thomasth@google.com></font></tt>
<br><tt><font size=2>> To: openstack@lists.openstack.org, </font></tt>
<br><tt><font size=2>> Date: 01/09/2014 04:51 AM</font></tt>
<br><tt><font size=2>> Subject: [Openstack] Force volume on same host
as VM</font></tt>
<br><tt><font size=2>> <br>
> Hi,</font></tt>
<br><tt><font size=2>> <br>
> I try to figure out how to force cinder volumes on the same host as
<br>
> the VM it is attached to (or will be attached to). OTOH, I would <br>
> still like to take advantage of nova-scheduler for automatic host
<br>
> selection for VMs. I don't want to use an availability zone per <br>
> host, because then the host selection would have to be done by the
<br>
> API client. So I'm wondering what the best solution for this use-<br>
> case might be.</font></tt>
<br><tt><font size=2>> <br>
> While researching, I stumbled upon topology aware placement [0] <br>
> which seems interesting, but I couldn't find any further information<br>
> about the status of it. Also, there seems to be some effort going
<br>
> into building a central scheduler instead of having nova-scheduler
<br>
> and cinder-scheduler [1][2], but again, I couldn't figure out what
<br>
> the current status of this is.</font></tt>
<br><tt><font size=2>> <br>
> So, my question is if this use-case will be better supported in the
<br>
> future (Icehouse maybe already?), and how a workaround could look
<br>
> like for now.</font></tt>
<br><tt><font size=2>> <br>
> Thanks a lot,</font></tt>
<br><tt><font size=2>> Thomas</font></tt>
<br><tt><font size=2>> <br>
> [0]: </font></tt><a href=https://etherpad.openstack.org/p/HavanaTopologyAwarePlacement><tt><font size=2>https://etherpad.openstack.org/p/HavanaTopologyAwarePlacement</font></tt></a>
<br><tt><font size=2>> [1]: </font></tt><a href="https://www.mail-archive.com/openstack-dev@lists.openstack.org/"><tt><font size=2>https://www.mail-archive.com/openstack-dev@lists.openstack.org/</font></tt></a><tt><font size=2><br>
> msg07981.html</font></tt>
<br><tt><font size=2>> [2]: </font></tt><a href="http://openstack.10931.n7.nabble.com/cinder-metrics-with-nova-"><tt><font size=2>http://openstack.10931.n7.nabble.com/cinder-metrics-with-nova-</font></tt></a><tt><font size=2><br>
> scheduler-tt22974.html#a23038</font></tt>
<br>
<br><tt><font size=2>As long as you schedule one thing after another, you
might miss the best answer.  Some of us are advocating getting to
the point where one scheduler makes a simultaneous decision about a whole
group of resources of various kinds.  There was some discussion of
the general idea at the Icehouse summit</font></tt>
<br>
<br><a href="https://etherpad.openstack.org/p/NovaIcehouse-Smart-Resource-Placement"><tt><font size=2>https://etherpad.openstack.org/p/NovaIcehouse-Smart-Resource-Placement</font></tt></a>
<br>
<br><tt><font size=2>The general issue is widely recognized and at least
somewhat appreciated, and not something we will be able to do in one cycle.
 We suggested a roadmap that starts with making Nova able to make
a decision about a heterogenous group of VMs all at once</font></tt>
<br>
<br><a href="https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API"><tt><font size=2>https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API</font></tt></a>
<br>
<br><tt><font size=2>and a relatively unambitious version (no nested grouping,
relatively familiar API phasing) of that was the recommended outcome.</font></tt>
<br>
<br><tt><font size=2>Two big changes were planned to happen to Nova first.
 One is incorporating Boris' suggestion to make the schedulers keep
a copy of the relevant hypervisor state in local memory.  The other
is a structural change to separate out the Nova scheduler (without increasing
its ambitions); this is now known as Gantt.  Those two should complete
before the instance group work is done.  Given where we are on the
calendar right now, I am not so sure how much instance group work will
get done in Icehouse.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>