Open Stack

On 11/01/2013 09:09 AM, Andrew Laski wrote:
> On 11/01/13 at 10:16am, John Garbutt wrote:
>> Its intentional. Cells is there to split up your nodes into more
>> manageable chunks.
> 
> I don't think you mean to say that there's intentionally a performance
> issue.  But yes there are performance issues with the filter scheduler. 
> Because I work on a deployment that uses cells to partition the workload
> I haven't seen them myself, but there are plenty of reports from others
> who have encountered them.  And it's easy to run some back of the napkin
> calculations like was done below and see that scheduling will require a
> lot of resources if there's no partitioning.
> 
>>
>> There are quite a few design summit sessions on looking into
>> alternative approaches to our current scheduler.
>>
>> While I would love a single scheduler to make everyone happy, I am
>> thinking we might end up with several scheduler, each with slightly
>> different properties, and you pick one depending on what you want to
>> do with your cloud.
> 
> +1.  We have the ability to drop in different schedulers right now, but
> there's only one really useful scheduler in the tree.  There has been
> talk of making a more performant scheduler which schedules in a 'good
> enough' fashion through some approximation algorithm.  I would love to
> see that get introduced as another scheduler and not as a rework of the
> filter scheduler.  I suppose the chance scheduler could technically
> count for that, but I'm under the impression that it isn't used beyond
> testing.

Agreed.

There's a lot of discussion happening in two different directions, it
seems.  One group is very interested in improving the scheduler's
ability to make the best decision possible using various policies.
Another group is concerned with massive scale and is willing to accept
"good enough" scheduling to get there.

I think the filter scheduler is pretty reasonable for the best possible
decision approach today.  There's some stuff that could perform better.
 There's more policy knobs that could be added.  There's the cross
service issue to figure out ... but it's not bad.

I'm very interested in a new "good enough" scheduler.  I liked the idea
of running a bunch of schedulers that each only look at a subset of your
infrastructure and pick something that's good enough.  I'm interested to
hear other ideas in the session we have on this topic (rethinking
scheduler design).

Of course, you get a lot of the massive scale benefits by going to
cells, too.  If cells is our answer here, I really want to see more
people stepping up to help with the cells code.  There are still some
feature gaps to fill.  We should also be looking at the road to getting
back to only having one way to deploy nova (cells).  Having both cells
vs non-cells options really isn't ideal long term.

-- 
Russell Bryant