On 09/30/2014 12: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 >> cascading >> >> 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 >>> 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. >> > > 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.
I agree with this. I know that there are folks who don't like cells - but I think that ship has sailed. It's there - which means we need to make it first class. > Resources can be made available if we can agree the direction but current > reviews are not progressing (such as > https://bugs.launchpad.net/nova/+bug/1211011) > > Tim > >> Thanks, >> John >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
