Open Stack

>> On Fri, Dec 5, 2014 at 8:23 AM, joehuang <joehuang at huawei.com> wrote:
>>> Dear all & TC & PTL,
>>>
>>> In the 40 minutes cross-project summit session “Approaches for
>>> scaling out”[1], almost 100 peoples attended the meeting, and the
>>> conclusion is that cells can not cover the use cases and
>>> requirements which the OpenStack cascading solution[2] aim to
>>> address, the background including use cases and requirements is
>>> also described in the mail.

I must admit that this was not the reaction I came away with the
discussion with.  There was a lot of confusion, and as we started
looking closer, many (or perhaps most) people speaking up in the room
did not agree that the requirements being stated are things we want to
try to satisfy.

On 12/05/2014 06:47 PM, joehuang wrote:
> Hello, Davanum,
> 
> Thanks for your reply.
> 
> Cells can't meet the demand for the use cases and requirements described in the mail. 

You're right that cells doesn't solve all of the requirements you're
discussing.  Cells addresses scale in a region.  My impression from the
summit session and other discussions is that the scale issues addressed
by cells are considered a priority, while the "global API" bits are not.

>> 1. Use cases
>> a). Vodafone use case[4](OpenStack summit speech video from 9'02"
>> to 12'30" ), establishing globally addressable tenants which result
>> in efficient services deployment.

Keystone has been working on federated identity.  That part makes sense,
and is already well under way.

>> b). Telefonica use case[5], create virtual DC( data center) cross
>> multiple physical DCs with seamless experience.

If we're talking about multiple DCs that are effectively local to each
other with high bandwidth and low latency, that's one conversation.  My
impression is that you want to provide a single OpenStack API on top of
globally distributed DCs.  I honestly don't see that as a problem we
should be trying to tackle.  I'd rather continue to focus on making
OpenStack work *really* well split into regions.

I think some people are trying to use cells in a geographically
distributed way, as well.  I'm not sure that's a well understood or
supported thing, though.  Perhaps the folks working on the new version
of cells can comment further.

>> c). ETSI NFV use cases[6], especially use case #1, #2, #3, #5, #6,
>> 8#. For NFV cloud, it’s in nature the cloud will be distributed but
>> inter-connected in many data centers.

I'm afraid I don't understand this one.  In many conversations about
NFV, I haven't heard this before.

>>
>> 2.requirements
>> a). The operator has multiple sites cloud; each site can use one or
>> multiple vendor’s OpenStack distributions.

Is this a technical problem, or is a business problem of vendors not
wanting to support a mixed environment that you're trying to work around
with a technical solution?

>> b). Each site with its own requirements and upgrade schedule while
>> maintaining standard OpenStack API
>> c). The multi-site cloud must provide unified resource management
>> with global Open API exposed, for example create virtual DC cross
>> multiple physical DCs with seamless experience.

>> Although a prosperity orchestration layer could be developed for
>> the multi-site cloud, but it's prosperity API in the north bound
>> interface. The cloud operators want the ecosystem friendly global
>> open API for the mutli-site cloud for global access.

I guess the question is, do we see a "global API" as something we want
to accomplish.  What you're talking about is huge, and I'm not even sure
how you would expect it to work in some cases (like networking).

In any case, to be as clear as possible, I'm not convinced this is
something we should be working on.  I'm going to need to see much more
overwhelming support for the idea before helping to figure out any
further steps.

-- 
Russell Bryant