Open Stack

Another topic that seem to be interesting for the folks in this group,
especially those interested in NFV and telcos. So far, I've seen the
original proposal and only a couple of comments against this.

The session in Paris was also quite busy. If you're interested in this,
consider joining the conversation on openstack-dev mailing list and give
your opinion about cells vs cascading (or just about the use cases that
are not covered by cells).

/stef


-------- Forwarded Message --------
Subject: [openstack-dev]  [all] [tc] [PTL] Cascading vs. Cells – summit
recap and move forward
Date: Fri, 5 Dec 2014 13:23:59 +0000
From: joehuang <joehuang at huawei.com>
Reply-To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>

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