← Back to team overview

nova-orchestration team mailing list archive

Re: [Nova-scaling] Tactical Scheduler/Scalability plan ...

 

Thanks Mark!

Good point on the use of the word cache. I'll adjust in the branch.

Not sure what the bounds are on the DB if there's proper indexing ... perhaps someone closer to db-land can answer that. Your question about zones will really depend on that answer. Also zones would still be required for hybrid cloud and bursting.

-S

________________________________________
From: nova-scaling-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx [nova-scaling-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx] on behalf of Mark Washenberger [mark.washenberger@xxxxxxxxxxxxx]
Sent: Tuesday, December 06, 2011 11:03 AM
To: nova-orchestration@xxxxxxxxxxxxxxxxxxx; nova-scaling@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Nova-scaling] Tactical Scheduler/Scalability plan ...

Great writeup, Sandy.

A few thoughts I had while reading it over:

- I love the command-query separation (CQRS) you've got here--it seems like the right way to scale (tremendously!) when you don't have millisecond consistency requirements.
- I don't really want to call DB table that the API is querying from a "cache". . cache to me implies that I will go to the slow source of data on a cache miss, which it didn't sound like you were proposing.
- If we succeed in creating this denormalized view of the instance data the API needs on GET /servers, for example, I think we could scale the API out to the full size of the deployment. What are the practical limitations? 100 million rows? more? (I'm really excited about this.) But my question is, if we can scale the API out really far why included it in a child zone at all?

"Sandy Walsh" <sandy.walsh@xxxxxxxxxxxxx> said:

> Hi y'all,
>
> Attached are some notes from the whiteboard noodling myself, comstud and
> anotherjesse did last week:
> http://wiki.openstack.org/EssexSchedulerImprovements
>
> It addresses some tactical problems we're facing and, hopefully, sets up a pattern
> for further improvements and hooks for things like orchestration.
>
> Look forward to your feedback!
>
> Cheers,
> Sandy
>
> --
> Mailing list: https://launchpad.net/~nova-scaling
> Post to     : nova-scaling@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~nova-scaling
> More help   : https://help.launchpad.net/ListHelp
>



--
Mailing list: https://launchpad.net/~nova-scaling
Post to     : nova-scaling@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~nova-scaling
More help   : https://help.launchpad.net/ListHelp


Follow ups

References