I admittedly only just saw the subject and skimmed the thread (so might be 
missing something), but have you looked into taking advantage of scheduler 
hints from a custom filter from the API / CLI?  As FYI, horizon has a patch up 
adding support for them [1].

[1] https://review.openstack.org/#/c/272635/


From: Dhvanan Shah <dhva...@gmail.com<mailto:dhva...@gmail.com>>
Reply-To: OpenStack List 
Date: Sunday, February 7, 2016 at 8:34 PM
To: "Jay com>" <jaypi...@gmail.com<mailto:jaypi...@gmail.com>>, OpenStack List 
Subject: Re: [openstack-dev] Dynamically adding Extra Specs

Hey Jay!

I was looking at implementing a few scheduling algorithms of my own natively 
into OpenStack, and for that I went through the nova-scheduler. After going 
through the scheduler, I felt that it was not very easy to implement or extend 
and add new scheduling algorithms to the scheduler. The only things that I felt 
that I could change or maybe was provisioned for adding or extending were the 
filters and weighers and implementing new scheduling algorithms with just these 
2 knobs was a little hard. I did change the code in the filter_scheduler to get 
some basic algorithms running like the first and next fit apart from the 
spreading and stacking which was already present. But to go beyond and to 
implement more complex algorithms was much harder and I would have to change a 
lot of code in different places that could as a side effect also break things 
and didn't seem clean. I might be wrong and might have not understood things 
right, please correct me if so.

To give an example of what I mean by a little complex scheduling algorithms: a 
subset matching algorithm - that schedules multiple heterogeneous requests by 
picking out a subset from the requests that best fit a host/s, so this would 
improve the utilization. The prerequisite for this is that I have multiple 
heterogeneous requests lined up to be scheduled. So for this kind of an 
algorithm it isnt easy to implement into OpenStack.

So a workaround that I'm working on for implementing different scheduling 
algorithms is by building a scheduling wrapper outside of the OpenStack 
architecture, where the user interacts with this wrapper and in the wrapper I 
get the host details from the database and based on the algorithm I want, the 
scheduler chooses the host for the request and gives out a VM : Host mapping 
(The wrapper does the sanity checks that the filters do to check if the host 
can accommodate or handle the request). Along with the request, I also want to 
pass this mapping that the scheduler can use to assign the request to the host 
passed in the mapping. I've written a filter that filters all the hosts apart 
from the host that I sent and this is how I make sure that the request gets 
placed on the host that I had passed. I have come up with a hack to pass the 
host to the scheduler, but it is not quite elegant.

Would be great to have your input on the same!

On Mon, Feb 8, 2016 at 12:51 AM, Jay Pipes 
<jaypi...@gmail.com<mailto:jaypi...@gmail.com>> wrote:
Apologies for the delayed responses. Comments inline.

On 01/27/2016 02:29 AM, Dhvanan Shah wrote:
Hey Jay!

Thanks for the clarification. There was another thing that I wanted to
know, is there any provision to pass extra arguments or some extra
specifications along with the VM request to nova. To give you some
context, I wanted to pass a host:vm mapping to the nova scheduler for
its host selection process, and I'm providing this mapping from outside
of the openstack architecture.

Why do you want to do this? The scheduler is the thing that sets the host -> vm 
mapping -- that's what the process of scheduling does.

> So I need to send this information along
with the request to the scheduler. One way of doing this was creating
new flavors with their extra specification as different hosts, but that
would lead to as you pointed out earlier a "flavor explosion" problem.

So is there a way to pass some extra arguments or some additional
information to nova.

Depends what exactly you are trying to pass to Nova. Could you give some more 
information about your use case?


Dhvanan Shah
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to