openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Wed, Feb 16, 2011 at 4:25 PM, Eric Day <eday@xxxxxxxxxxxx> wrote:
> 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. :)

And I also raised concerns about performance of having Nova not
understand the relationships of multi-tenancy. ;)

Unfortunately, I am still unclear as to what precisely you are
proposing that Sandy change before going any further in his work.
Could you be specific on what steps you feel Sandy et al should take
that would eliminate your worry about scalability? What specifically
are the foundations that you want to rework? And are these realistic
to get done in Cactus?

-jay