nova-scaling team mailing list archive
-
nova-scaling team
-
Mailing list archive
-
Message #00015
Re: 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