>> On Fri, Dec 5, 2014 at 8:23 AM, joehuang <joehu...@huawei.com> wrote: >>> Dear all & TC & PTL, >>> >>> In the 40 minutes cross-project summit session “Approaches for >>> scaling out”, 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 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(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, 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, 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 _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev