nova-orchestration team mailing list archive

["Mark Washenberger" <mark.washenberger@xxxxxxxxxxxxx>]

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
>