Open Stack

On Tue, Sep 30, 2014 at 7:35 AM, John Garbutt <john at johngarbutt.com> wrote:

> On 30 September 2014 14:04, joehuang <joehuang at 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 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: https://wiki.openstack.org/wiki/OpenStack_cascading_solution
> > [2] PoC source code: https://github.com/stackforge/tricircle
> > [3] Live demo video at YouTube:
> https://www.youtube.com/watch?v=OSU6PYRz5qY
> > [4] Live demo video at Youku (low quality, for those who can't access
> YouTube)：http://v.youku.com/v_show/id_XNzkzNDQ3MDg4.html
> > [5]
> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg36395.html
>
> There are etherpads for suggesting cross project sessions here:
> https://wiki.openstack.org/wiki/Summit/Planning
> https://etherpad.openstack.org/p/kilo-crossproject-summit-topics
>
> I am interested at comparing this to Nova's cells concept:
>
> http://docs.openstack.org/trunk/config-reference/content/section_compute-cells.html
>
> Cells basically scales out a single datacenter region by aggregating
> multiple child 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 database 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 regions.
>
> 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.
>
> Thanks,
> John
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

​Interesting idea, to be honest when TripleO was first announced what you
have here is more along the lines of what I envisioned.  It seems that this
would have some interesting wins in terms of upgrades, migrations and
scaling in general.  Anyway, you should propose it to the etherpad as John
G ( the other John G :) ) recommended, I'd love to dig deeper into this.

Thanks,
John​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140930/9b64437a/attachment.html>