Open Stack

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 <jaypipes at gmail.com
> <mailto:jaypipes at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev