Open Stack

Hello,  Andrew, 

> I do consider this to be out of scope for cells, for at least the medium
> term as you've said.  There is additional complexity in making that a
> supported configuration that is not being addressed in the cells
> effort.  I am just making the statement that this is something cells
> could address if desired, and therefore doesn't need an additional solution

1. Does your solution include Cinder,Neutron, Glance, Ceilometer, or only Nova involved? Could you describe it more clear how your solution works.
2. The tenant's resources need to be distributed in different data centers, how these resources are connected through L2/L3 networing, and isolated from other tenants, including provide advanced service like LB/FW/VPN, and service chainning?
3. How to distribute the image to geo-distributed data-centers when the user upload image, or you mean all VM will boot from the remote image data?
4. How would the metering and monitoring function will work in geo-distributed data-centers? Or say, if we use Ceilometer, how to hadnle the sampling data/alarm?
5. How to support multi-vendor's OpenStack distribution in one multi-site cloud? If only support one vendor's OpenStack distribution, and use RPC for inter-dc communication, how to do the cross data center integration and troubleshooting, upgrade with RPC if the driver/agent/backend(storage/network/sever) from different vendor

I have lots of doubts how the cells would address these challenges,  these questions are only part of them. It would be the best if cells can address all challenges, then of course no need an adtional solution.

Best regards

Chaoyi Huang ( joehuang )

____________________________
From: Andrew Laski [andrew.laski at rackspace.com]
Sent: 13 December 2014 0:06
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

On 12/12/2014 09:50 AM, Russell Bryant wrote:
> On 12/11/2014 12:55 PM, Andrew Laski wrote:
>> Cells can handle a single API on top of globally distributed DCs.  I
>> have spoken with a group that is doing exactly that.  But it requires
>> that the API is a trusted part of the OpenStack deployments in those
>> distributed DCs.
> And the way the rest of the components fit into that scenario is far
> from clear to me.  Do you consider this more of a "if you can make it
> work, good for you", or something we should aim to be more generally
> supported over time?  Personally, I see the globally distributed
> OpenStack under a single API case much more complex, and worth
> considering out of scope for the short to medium term, at least.

I do consider this to be out of scope for cells, for at least the medium
term as you've said.  There is additional complexity in making that a
supported configuration that is not being addressed in the cells
effort.  I am just making the statement that this is something cells
could address if desired, and therefore doesn't need an additional solution.

> For me, this discussion boils down to ...
>
> 1) Do we consider these use cases in scope at all?
>
> 2) If we consider it in scope, is it enough of a priority to warrant a
> cross-OpenStack push in the near term to work on it?
>
> 3) If yes to #2, how would we do it?  Cascading, or something built
> around cells?
>
> I haven't worried about #3 much, because I consider #2 or maybe even #1
> to be a show stopper here.
>


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev