Hello, Davanum, Thanks for your reply.
Cells can't meet the demand for the use cases and requirements described in the mail. > 1. Use cases > a). Vodafone use case[4](OpenStack summit speech video from 9'02" to 12'30" > ), establishing globally addressable tenants which result in efficient > services deployment. > b). Telefonica use case[5], create virtual DC( data center) cross multiple > physical DCs with seamless experience. > c). ETSI NFV use cases[6], especially use case #1, #2, #3, #5, #6, 8#. For > NFV cloud, it’s in nature the cloud will be distributed but inter-connected > in many data centers. > > 2.requirements > a). The operator has multiple sites cloud; each site can use one or multiple > vendor’s OpenStack distributions. > b). Each site with its own requirements and upgrade schedule while > maintaining standard OpenStack API > c). The multi-site cloud must provide unified resource management with global > Open API exposed, for example create virtual DC cross multiple physical DCs > with seamless experience. > Although a prosperity orchestration layer could be developed for the > multi-site cloud, but it's prosperity API in the north bound interface. The > cloud operators want the ecosystem friendly global open API for the > mutli-site cloud for global access. Best Regards Chaoyi Huang ( joehuang ) ________________________________________ From: Davanum Srinivas [dava...@gmail.com] Sent: 05 December 2014 21:56 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward Joe, Related to this topic, At the summit, there was a session on Cells v2 and following up on that there have been BP(s) filed in Nova championed by Andrew - https://review.openstack.org/#/q/owner:%22Andrew+Laski%22+status:open,n,z thanks, dims On Fri, Dec 5, 2014 at 8:23 AM, joehuang <joehu...@huawei.com> wrote: > Dear all & TC & PTL, > > In the 40 minutes cross-project summit session “Approaches for scaling > out”[1], almost 100 peoples attended the meeting, and the conclusion is that > cells can not cover the use cases and requirements which the OpenStack > cascading solution[2] aim to address, the background including use cases and > requirements is also described in the mail. > > After the summit, we just ported the PoC[3] source code from IceHouse based > to Juno based. > > Now, let's move forward: > > The major task is to introduce new driver/agent to existing core projects, > for the core idea of cascading is to add Nova as the hypervisor backend of > Nova, Cinder as the block storage backend of Cinder, Neutron as the backend > of Neutron, Glance as one image location of Glance, Ceilometer as the store > of Ceilometer. > a). Need cross-program decision to run cascading as an incubated project mode > or register BP separately in each involved project. CI for cascading is quite > different from traditional test environment, at least 3 OpenStack instance > required for cross OpenStack networking test cases. > b). Volunteer as the cross project coordinator. > c). Volunteers for implementation and CI. > > Background of OpenStack cascading vs cells: > > 1. Use cases > a). Vodafone use case[4](OpenStack summit speech video from 9'02" to 12'30" > ), establishing globally addressable tenants which result in efficient > services deployment. > b). Telefonica use case[5], create virtual DC( data center) cross multiple > physical DCs with seamless experience. > c). ETSI NFV use cases[6], especially use case #1, #2, #3, #5, #6, 8#. For > NFV cloud, it’s in nature the cloud will be distributed but inter-connected > in many data centers. > > 2.requirements > a). The operator has multiple sites cloud; each site can use one or multiple > vendor’s OpenStack distributions. > b). Each site with its own requirements and upgrade schedule while > maintaining standard OpenStack API > c). The multi-site cloud must provide unified resource management with global > Open API exposed, for example create virtual DC cross multiple physical DCs > with seamless experience. > Although a prosperity orchestration layer could be developed for the > multi-site cloud, but it's prosperity API in the north bound interface. The > cloud operators want the ecosystem friendly global open API for the > mutli-site cloud for global access. > > 3. What problems does cascading solve that cells doesn't cover: > OpenStack cascading solution is "OpenStack orchestrate OpenStacks". The core > architecture idea of OpenStack cascading is to add Nova as the hypervisor > backend of Nova, Cinder as the block storage backend of Cinder, Neutron as > the backend of Neutron, Glance as one image location of Glance, Ceilometer as > the store of Ceilometer. Thus OpenStack is able to orchestrate OpenStacks > (from different vendor's distribution, or different version ) which may > located in different sites (or data centers ) through the OpenStack API, > meanwhile the cloud still expose OpenStack API as the north-bound API in the > cloud level. > > 4. Why cells can’t do that: > Cells provide the scale out capability to Nova, but from the OpenStack as a > whole point of view, it’s still working like one OpenStack instance. > a). if Cells is deployed with shared Cinder, Neutron, Glance, Ceilometer. > This approach provides the multi-site cloud with one unified API endpoint and > unified resource management, but consolidation of multi-vendor/multi-version > OpenStack instances across one or more data centers cannot be fulfilled. > b). Each site installed one child cell and accompanied standalone Cinder, > Neutron(or Nova-network), Glance, Ceilometer. This approach makes > multi-vendor/multi-version OpenStack distribution co-existence in multi-site > seem to be feasible, but the requirement for unified API endpoint and unified > resource management cannot be fulfilled. Cross Neutron networking automation > is also missing, which should otherwise be done manually or use proprietary > orchestration layer. > > For more information about cascading and cells, please refer to the > discussion thread before Paris Summit [7]. > > [1]Approaches for scaling out: > https://etherpad.openstack.org/p/kilo-crossproject-scale-out-openstack > [2]OpenStack cascading solution: > https://wiki.openstack.org/wiki/OpenStack_cascading_solution > [3]Cascading PoC: https://github.com/stackforge/tricircle > [4]Vodafone use case (9'02" to 12'30"): > https://www.youtube.com/watch?v=-KOJYvhmxQI > [5]Telefonica use case: > http://www.telefonica.com/en/descargas/mwc/present_20140224.pdf > [6]ETSI NFV use cases: > http://www.etsi.org/deliver/etsi_gs/nfv/001_099/001/01.01.01_60/gs_nfv001v010101p.pdf > [7]Cascading thread before design summit: > http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-td54115.html > > Best Regards > Chaoyi Huang (joehuang) > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims _______________________________________________ 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