So I have substantial concerns about hierarchy based designs and data
mass - the interconnect between leaves in the hierarchy are often
going to be fairly thin, particularly if they are geographically
distributed, so the semantics of what is allowed to access what data
resource (glance, swift, cinder, manilla) need some very careful
thought, and the way those restrictions are portrayed to the user to
avoid confusion needs even more thought.

On 30 September 2014 14:04, joehuang <> 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 interface);
> 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:
> [2] PoC source code:
> [3] Live demo video at YouTube:
> [4] Live demo video at Youku (low quality, for those who can't access 
> YouTube):
> [5] 
> Best Regards
> Chaoyi Huang ( Joe Huang )
> _______________________________________________
> OpenStack-dev mailing list

Duncan Thomas

OpenStack-dev mailing list

Reply via email to