<div dir="ltr">There was work done on enabling much more dynamic scheduling, including cross project scheduling (e.g. get additional placement hints from Neutron or Cinder), and I believe the framework is even in place to make use of this, but I don't believe anyone has written a scheduling component to make use of this. I think your best bet would be to build a custom weighted scheduler, which could be as simple as a linearly decreasing weight for one group and the inverse for the other group. Certainly this wouldn't be perfect, but might address your needs.<div><br></div><div>Robert</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 3, 2016 at 8:36 AM, Jonathan Proulx <span dir="ltr"><<a href="mailto:jon@csail.mit.edu" target="_blank">jon@csail.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Mar 02, 2016 at 09:35:07PM -0500, Mathieu Gagné wrote:<br>
:What would prevent the next user from having workloadB collocated with<br>
<span class="">:an other user's workloadA if that's the only capacity available?<br>
:<br>
:Unless aggregates are used, it will be hard to guaranty that workloadA<br>
:and workloadB (from any users) are never collocated.<br>
:<br>
:You could probably play with custom weighers where a specialized<br>
:aggregate would be preferred over the others unless there isn't capacity<br>
:left. This would also mean that strict filters can't be used anymore<br>
:like suggested. (and it will need custom Python code to be written)<br>
:<br>
:The main challenge I see is not the single first anti-affinity request,<br>
:it's all the subsequent others which will also require anti-affinity.<br>
<br>
<br>
</span>My reading of the question suggesst they don't want a 'hard<br>
never|always colocate' which hsot aggregates and server groups have<br>
ways of enforcing, but rather a 'soft preference to avoid|achieve<br>
colocation'.<br>
<br>
I don't think there's an existing way to do this other than writing a<br>
custom weighter.<br>
<br>
I've frequntly wished for this scheduling option but not hard enough<br>
to implement it myself...<br>
<br>
-Jon<br>
<br>
:<br>
:Mathieu<br>
<div><div class="h5">:<br>
:On 2016-03-02 8:46 PM, Adam Lawson wrote:<br>
:> Hi Kris,<br>
:><br>
:> When using aggregates as an example, anyone can assign<br>
:> workloadA<>aggregateA and workloadB<>aggregateB. That's easy. But if we<br>
:> have outstanding requests for workloadB and have a glut of capacity in<br>
:> aggregateA, workloadB won't be able to use those hosts so we have spare<br>
:> capacity and no way to utilize it.<br>
:><br>
:> So I want to set an affinity for workloads and not at the host level.<br>
:> That way, hosts remain fungible, workload affinity policies are<br>
:> respected and cloud capacity is properly utilizing capacity.<br>
:><br>
:> Does that make sense?<br>
:><br>
:> //adam<br>
:><br>
:> */<br>
:> Adam Lawson/*<br>
:><br>
:> AQORN, Inc.<br>
:> 427 North Tatnall Street<br>
:> Ste. 58461<br>
:> Wilmington, Delaware 19801-2230<br>
:> Toll-free: (844) 4-AQORN-NOW ext. 101<br>
:> International: +1 302-387-4660<br>
:> Direct: +1 916-246-2072<br>
:><br>
:> On Wed, Mar 2, 2016 at 3:08 PM, Kris G. Lindgren <<a href="mailto:klindgren@godaddy.com">klindgren@godaddy.com</a><br>
:> <mailto:<a href="mailto:klindgren@godaddy.com">klindgren@godaddy.com</a>>> wrote:<br>
:><br>
:> You can set attributes on flavors that must match the attributes on<br>
:> hosts or the host aggregates. So you can basically always make sure<br>
:> a specific flavors goes to a specific compute node or type (like<br>
:> disks=ssd or class=gpu). Look at nova flavor extra_specs<br>
:> documentation and the aggregate_Instance_extra_specs under the<br>
:> scheduler options.<br>
:><br>
:><br>
:> ___________________________________________________________________<br>
:> Kris Lindgren<br>
:> Senior Linux Systems Engineer<br>
:> GoDaddy<br>
:><br>
:> From: "Fox, Kevin M" <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a> <mailto:<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>>><br>
:> Date: Wednesday, March 2, 2016 at 3:58 PM<br>
:> To: Adam Lawson <<a href="mailto:alawson@aqorn.com">alawson@aqorn.com</a> <mailto:<a href="mailto:alawson@aqorn.com">alawson@aqorn.com</a>>>,<br>
:> "<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
:> <mailto:<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>>"<br>
:> <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
:> <mailto:<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>>><br>
:> Subject: Re: [Openstack-operators] Setting affinity based on<br>
:> instance type<br>
:><br>
:> you usually do that on an instance level with server groups. do you<br>
:> have an example where you might want to do it at the flavor level?<br>
:><br>
:> Thanks,<br>
:> Kevin<br>
:> ------------------------------------------------------------------------<br>
:> *From:* Adam Lawson [<a href="mailto:alawson@aqorn.com">alawson@aqorn.com</a> <mailto:<a href="mailto:alawson@aqorn.com">alawson@aqorn.com</a>>]<br>
:> *Sent:* Wednesday, March 02, 2016 2:48 PM<br>
:> *To:* <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
:> <mailto:<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>><br>
:> *Subject:* [Openstack-operators] Setting affinity based on instance type<br>
:><br>
:> I'm sure this is possible but I'm trying to find the info I need in<br>
:> the docs so I figured I'd pitch this to you guys while I continue<br>
:> looking:<br>
:><br>
:> Is it possible to set an affinity/anti-affinity policy to ensure<br>
:> instance Type A is weighted for/against co-location on the same<br>
:> physical host with instance Type B?<br>
:><br>
:> Basically I have no requirement for server-group affinity but rather<br>
:> to ensure specific workloads are as separate as possible.<br>
:><br>
:> Thoughts?<br>
:><br>
:> //adam<br>
:><br>
:> */<br>
:> Adam Lawson/*<br>
:><br>
:> AQORN, Inc.<br>
:> 427 North Tatnall Street<br>
:> Ste. 58461<br>
:> Wilmington, Delaware 19801-2230<br>
:> Toll-free: (844) 4-AQORN-NOW ext. 101<br>
:> International: <a href="tel:%2B1%20302-387-4660" value="+13023874660">+1 302-387-4660</a> <tel:%2B1%20302-387-4660><br>
:> Direct: +1 916-246-2072 <tel:%2B1%20916-246-2072><br>
:><br>
:><br>
:><br>
:><br>
:> _______________________________________________<br>
:> OpenStack-operators mailing list<br>
:> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
:> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
:><br>
:<br>
:<br>
:_______________________________________________<br>
:OpenStack-operators mailing list<br>
:<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
:<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
</div></div>--<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>