[openstack-dev] Cross-Project meeting, Tue December 9th, 21:00 UTC
joehuang at huawei.com
Tue Dec 9 09:33:47 UTC 2014
If time is available, how about adding one agenda to guide the direction for cascading to move forward? Thanks in advance.
The topic is : " 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. "
In the 40 minutes cross-project summit session "Approaches for scaling out", 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 aim to address, the background including use cases and requirements is also described in the mail.
After the summit, we just ported the PoC 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. (Already 6 engineers working on cascading in the project StackForge/tricircle)
Background of OpenStack cascading vs cells:
1. Use cases
a). Vodafone use case(OpenStack summit speech video from 9'02" to 12'30" ), establishing globally addressable tenants which result in efficient services deployment.
b). Telefonica use case, create virtual DC( data center) cross multiple physical DCs with seamless experience.
c). ETSI NFV use cases, 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.
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 .
Approaches for scaling out: https://etherpad.openstack.org/p/kilo-crossproject-scale-out-openstack
OpenStack cascading solution: https://wiki.openstack.org/wiki/OpenStack_cascading_solution
Cascading PoC: https://github.com/stackforge/tricircle
Vodafone use case (9'02" to 12'30"): https://www.youtube.com/watch?v=-KOJYvhmxQI
Telefonica use case: http://www.telefonica.com/en/descargas/mwc/present_20140224.pdf
ETSI NFV use cases: http://www.etsi.org/deliver/etsi_gs/nfv/001_099/001/01.01.01_60/gs_nfv001v010101p.pdf
Cascading thread before design summit: http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-td54115.html
Chaoyi Huang ( Joe Huang )
From: Thierry Carrez [mailto:thierry at openstack.org]
Sent: Tuesday, December 09, 2014 4:39 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Cross-Project meeting, Tue December 9th, 21:00 UTC
Dear PTLs, cross-project liaisons and anyone else interested,
We'll have a cross-project meeting Tuesday at 21:00 UTC, with the following agenda:
* Convergence on specs process (johnthetubaguy)
* Approval process differences
* Path structure differences
* specs.o.o aspect differences (toc)
* osprofiler config options (kragniz)
* Glance uses a different name from other projects
* Consensus on what name to use
* Open discussion & announcements
See you there !
For more details, please see:
Thierry Carrez (ttx)
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev