On Wed, Feb 16, 2011 at 03:59:10PM -0500, Jay Pipes wrote: > But, as I mentioned to Sandy on IRC, caching and performance should be > a secondary concern. The primary concern, right now, is just making > this all work. In other words, getting multiple zones up and running, > each knowing about their little slice of the pie, and communicating up > and down the scheduler levels properly. > > Optimization can come later.
While I would agree with this most of the time, there are some cases where "optimizing later" just doesn't work. Or, "optimizing" means rewriting everything you've done and replacing it with something that will scale seamlessly. I've done this a fair share myself over the years, and many of us have probably done it or seen it happen elsewhere. I was hoping to use past experiences and foresight to prevent a similar outcome with Nova. I'm not confident the current Nova database and messaging foundations will hold up (even with optimizations) for the scale, security, and user experience we are targeting. Spending more time on reworking those foundations before diving right into implementing the distributed aspects (multi-zone) is what I was trying to do and advocate. I recognize I'm in the minority with this opinion and it doesn't seem to be the route we'll take, so I hope to be proven wrong. :) -Eric _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : email@example.com Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp