Open Stack

Aha, right after replied Harsock's mail, I realized I'm correct still. Glad that I did graduated from the school :)

--jyh

> -----Original Message-----
> From: Jiang, Yunhong [mailto:yunhong.jiang at intel.com]
> Sent: Friday, November 01, 2013 10:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova][scheduler]The database access in the
> scheduler filters
> 
> As Shawn Hartsock pointed out in the reply, I made a stupid error in the
> calculation. It's in fact 55 access per second, not that big number I
> calculated.
> I thought I graduated from elementary school but seems I'm wrong. Really
> sorry for the stupid error.
> 
> --jyh
> 
> > -----Original Message-----
> > From: Russell Bryant [mailto:rbryant at redhat.com]
> > Sent: Friday, November 01, 2013 9:18 AM
> > To: openstack-dev at lists.openstack.org
> > Subject: Re: [openstack-dev] [nova][scheduler]The database access in
> the
> > scheduler filters
> >
> > 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
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev