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
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
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
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
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
For more information about cascading and cells, please refer to the discussion
thread before Paris Summit .
Approaches for scaling out:
OpenStack cascading solution:
Cascading PoC: https://github.com/stackforge/tricircle