[openstack-dev] [all] [tc] [PTL] Cascading vs. Cells – summit recap and move forward

Davanum Srinivas davanum at gmail.com
Fri Dec 5 13:56:46 UTC 2014


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 -


On Fri, Dec 5, 2014 at 8:23 AM, joehuang <joehuang at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Davanum Srinivas :: https://twitter.com/dims

More information about the OpenStack-dev mailing list