Dhvanan Shah wrote:
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.
Why use the filter mechanism at all?
Just provide a whole new scheduler that replaces the plugabble point
that already exists (a class with ``def select_destinations(self,
context, spec_obj)``)?
Although it seems u want to put a request into SCHEDULING_WAIT (or
something like that) and then when u have enough requests to batch up u
will move from SCHEDULING_WAIT -> SCHEDULING (something akin to delayed
scheduling when you have reached your batch size). Is something like
that correct?
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?
Thanks!
-jay
--
Dhvanan Shah
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
