<div dir="ltr"><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Matt Riedemann</b> <span dir="ltr"><<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>></span><br>Date: Thu, May 18, 2017 at 6:53 PM<br>Subject: [openstack-dev] [nova] Boston Forum session recap - instance/volume affinity for HPC<br>To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br><br><br>The etherpad for this session is here [1]. This was about discussing ways to achieve co-location or affinity for VMs and volumes for high-performance, and was spurred by an older dev list discussion (linked in the etherpad).<br>
<br>
This quickly grew into side discussions and it became apparent that at a high level we were talking about complicated solutions looking for a problem. That is also touched on a bit after the session in the dev ML [2].<br>
<br>
The base use case is a user wants their server instance and volume located as close to each other as possible, ideally on the same compute host.<br>
<br>
We talked about ways to model a sort of "distance" attribute between resource providers in an aggregate relationship (in the placement sense of 'aggregate', not compute host aggregates in nova). This distance or nearness idea led down a path for how you define distance in a cloud, i.e. does 'near' mean the same host or rack or data center in a particular cloud? How are these values defined - would they be custom per cloud and if so, how is that discoverable/inter-operable for an end API user? It was noted that flavors aren't inter-operable either really, at least not by name. Jay Pipes has an older spec [3] about generic scheduling which could replace server groups, so this could maybe fall into that.<br>
<br>
When talking about this there are also private cloud biases, i.e. things people are willing to tolerate or expose to their users because they are running a private cloud. Those same things don't all work in a public cloud, e.g. mapping availability zones one-to-one for cinder-volume and nova-compute on the same host when you have hundreds of thousands of hosts.<br>
<br>
Then there are other questions about if/how people have already solved this using things like flavors with extra specs and host aggregates and the AggregateInstanceExtraSpecsFil<wbr>ter, or setting [cinder]cross_az_attach=False in nova.conf on certain hosts. For example, setup host aggregates with nova-compute and cinder-volume running on the same host, define flavors with extra specs that match the host aggregate metadata, and then charge more for those flavors as your HPC type. Or, can we say, use Ironic?<br>
<br>
It's clear that we don't have a good end-user story for this requirement, and so I think next steps for this are going to involve working with the public cloud work group [4] and/or product work group [5] (hopefully those two groups could work together here) on defining the actual use cases and what the end user experience looks like.<br>
<br>
[1] <a href="https://etherpad.openstack.org/p/BOS-forum-compute-instance-volume-affinity-hpc" rel="noreferrer" target="_blank">https://etherpad.openstack.org<wbr>/p/BOS-forum-compute-instance-<wbr>volume-affinity-hpc</a><br>
[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-May/116694.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pip<wbr>ermail/openstack-dev/2017-May/<wbr>116694.html</a><br>
[3] <a href="https://review.openstack.org/#/c/183837/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/183837/</a><br>
[4] <a href="https://wiki.openstack.org/wiki/PublicCloudWorkingGroup" rel="noreferrer" target="_blank">https://wiki.openstack.org/wik<wbr>i/PublicCloudWorkingGroup</a><br>
[5] <a href="https://wiki.openstack.org/wiki/ProductTeam" rel="noreferrer" target="_blank">https://wiki.openstack.org/wik<wbr>i/ProductTeam</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<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></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="font-size:small">-- </span><br style="font-size:small"><div style="font-size:small"><div dir="ltr"><div dir="ltr">Kind regards,<br><br>Melvin Hillsman</div><div dir="ltr"><a href="mailto:mrhillsman@gmail.com" style="color:rgb(17,85,204)" target="_blank">mrhillsman@gmail.com</a><br>mobile: (832) 264-2646<br><br>Learner | Ideation | Belief | Responsibility | Command</div></div></div></div></div></div></div></div></div>
</div>