← Back to team overview

nova-orchestration team mailing list archive

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

 

Mark,

Right now we're mostly ignoring bursting as we should optimize for 'trusted zones' first, so I'm not sure there are any documents about bursting requirements yet.  I purposely try not to think about bursting too much...yet. ;)  

- Chris


On Dec 6, 2011, at 9:05 AM, Mark Washenberger wrote:

> Ah, good point about bursting. I feel like I should know the answer to this question, but are there some documents I can read about the requirements for and decisions we've made about bursting?
> 
> "Sandy Walsh" <sandy.walsh@xxxxxxxxxxxxx> said:
> 
>> 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
>> 
>> --
>> 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



References