On 09/30/2014 03:07 PM, Tim Bell wrote:
-----Original Message-----
From: John Garbutt [mailto:j...@johngarbutt.com]
Sent: 30 September 2014 15:35
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack

On 30 September 2014 14:04, joehuang <joehu...@huawei.com> wrote:
Hello, Dear TC and all,

Large cloud operators prefer to deploy multiple OpenStack instances(as
different zones), rather than a single monolithic OpenStack instance because of
these reasons:
1) Multiple data centers distributed geographically;
2) Multi-vendor business policy;
3) Server nodes scale up modularized from 00's up to million;
4) Fault and maintenance isolation between zones (only REST

At the same time, they also want to integrate these OpenStack instances into
one cloud. Instead of proprietary orchestration layer, they want to use standard
OpenStack framework for Northbound API compatibility with HEAT/Horizon or
other 3rd ecosystem apps.
We call this pattern as "OpenStack Cascading", with proposal described by
[1][2]. PoC live demo video can be found[3][4].
Nova, Cinder, Neutron, Ceilometer and Glance (optional) are involved in the
OpenStack cascading.
Kindly ask for cross program design summit session to discuss OpenStack
cascading and the contribution to Kilo.
Kindly invite those who are interested in the OpenStack cascading to work
together and contribute it to OpenStack.
(I applied for “other projects” track [5], but it would be better to
have a discussion as a formal cross program session, because many core
programs are involved )

[1] wiki: https://wiki.openstack.org/wiki/OpenStack_cascading_solution
[2] PoC source code: https://github.com/stackforge/tricircle
[3] Live demo video at YouTube:
[4] Live demo video at Youku (low quality, for those who can't access
There are etherpads for suggesting cross project sessions here:

I am interested at comparing this to Nova's cells concept:

Cells basically scales out a single datacenter region by aggregating multiple 
Nova installations with an API cell.

Each child cell can be tested in isolation, via its own API, before joining it 
up to
an API cell, that adds it into the region. Each cell logically has its own 
and message queue, which helps get more independent failure domains. You can
use cell level scheduling to restrict people or types of instances to particular
subsets of the cloud, if required.

It doesn't attempt to aggregate between regions, they are kept independent.
Except, the usual assumption that you have a common identity between all

It also keeps a single Cinder, Glance, Neutron deployment per region.

It would be great to get some help hardening, testing, and building out more of
the cells vision. I suspect we may form a new Nova subteam to trying and drive
this work forward in kilo, if we can build up enough people wanting to work on
improving cells.

At CERN, we've deployed cells at scale but are finding a number of architectural issues 
that need resolution in the short term to attain feature parity. A vision of "we all 
run cells but some of us have only one" is not there yet. Typical examples are 
flavors, security groups and server groups, all of which are not yet implemented to the 
necessary levels for cell parent/child.

We would be very keen on agreeing the strategy in Paris so that we can ensure 
the gap is closed, test it in the gate and that future features cannot 
'wishlist' cell support.

Resources can be made available if we can agree the direction but current 
reviews are not progressing (such as 

I am working on putting together this strategy so we can discuss it in Paris. I, and perhaps a few others, will be spending time on this in Kilo so that these thing do progress.

There are some good ideas in this thread and scaling out is a concern we need to continually work on. But we do have a solution that addresses this to an extent so I think the conversation should be about how we scale past cells, not replicate it.



OpenStack-dev mailing list
OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to