x
/
trio2o
Code Issues Proposed changes
Trio2o is to provide APIs gateway for multiple OpenStack clouds to act as a single OpenStack cloud.
229 Commits 2 Branches 12 Tags 4.1 MiB
Python 80.6%
Shell 15.1%
reStructuredText 4.3%
Go to file
yinxiulin 707c914e30 Nova_APIGW REST API Microversion Support 
1. What is the problem
The current Nova_APIGW does not support microversion function, the service
controller uses a fixed API version number to initialize novaclient

2. What is the solution to the problem
When the service controller receives an API request, it will get the
microversion number from request headers , and use this to initialize
novaclient.

For how to get the microversion number, please refer to:
https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html

The microversion supported range is 2.1 to latest version

3. What the features need to be implemented to the Tricircle
   to realize the solution
   Nova_APIGW microversion support added

Change-Id: Idf44c91100e5cb8ad0355164c9be991aa54a652b
 		2016-09-05 18:33:40 +08:00
cmd Move statless design from experiment to master branch 2016-01-14 12:56:57 +08:00
devstack Fix regex expresion error in integration test 2016-07-25 18:58:49 +08:00
doc/source Align project files structure with cookiecutter template 2016-07-05 15:08:41 +08:00
etc Add network type support to the Tricircle plugin 2016-06-21 20:11:24 +08:00
releasenotes Align project files structure with cookiecutter template 2016-07-05 15:08:41 +08:00
specs Merge "Add cross-pod L2 Networking spec file" 2016-06-17 01:30:39 +00:00
tricircle Nova_APIGW REST API Microversion Support 2016-09-05 18:33:40 +08:00
.coveragerc Align project files structure with cookiecutter template 2016-07-05 15:08:41 +08:00
.gitignore Change the gate to OpenStack infrastrucure 2015-12-15 12:09:09 +08:00
.gitreview Update .gitreview for new namespace 2015-10-17 22:41:25 +00:00
.testr.conf Add the Tricircle tempest plugin with a sample test case 2016-06-08 12:51:38 +08:00
CONTRIBUTING.rst Align project files structure with cookiecutter template 2016-07-05 15:08:41 +08:00
HACKING.rst Align project files structure with cookiecutter template 2016-07-05 15:08:41 +08:00
LICENSE Add source code to Tricircle 2014-09-25 15:56:40 +08:00
MANIFEST.in Align project files structure with cookiecutter template 2016-07-05 15:08:41 +08:00
README.rst Urgent fix the link error in the README.rst 2016-07-05 17:16:54 +08:00
requirements.txt Updated from global requirements 2016-08-13 01:38:47 +00:00
setup.cfg Add shared vlan type driver 2016-07-20 11:15:00 +08:00
setup.py Manual sync from global-requirements 2016-05-26 13:23:29 +10:00
test-requirements.txt Updated from global requirements 2016-06-25 20:27:57 +00:00
tox.ini Enable DeprecationWarning in test environments 2016-08-14 05:35:42 +00:00

README.rst

Tricircle

The Tricircle provides an OpenStack API gateway and networking automation funtionality to allow multiple OpenStack instances, spanning in one site or multiple sites or in hybrid cloud, to be managed as a single OpenStack cloud.

The Tricircle and these managed OpenStack instances will use shared KeyStone (with centralized or distributed deployment) or federated KeyStones for identity management.

The Tricircle presents one big region to the end user in KeyStone. And each OpenStack instance called a pod is a sub-region of the Tricircle in KeyStone, and usually not visible to end user directly.

The Tricircle acts as OpenStack API gateway, can handle OpenStack API calls, schedule one proper OpenStack instance if needed during the API calls handling, forward the API calls to the appropriate OpenStack instance, and deal with tenant level L2/L3 networking across OpenStack instances automatically. So it doesn't matter on which bottom OpenStack instance the VMs for the tenant are running, they can communicate with each other via L2 or L3.

The end user can see avaialbility zone(AZ) and use AZ to provision VM, Volume, even Network through the Tricircle. One AZ can include many OpenStack instances, the Tricircle can schedule and bind OpenStack instance for the tenant inside one AZ. A tenant's resources could be bound to multiple specific bottom OpenStack instances in one or multiple AZs automatically.