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