0d0ca11e95
1.What is the problem: Python requests lib is used to forward the http request from the Cinder API-GW to bottom Cinder. Now the latest version of the requests lib add stricter header validity check: only bytes or string is allowed for header item's value, other value will lead to exception, even for "None". But Cinder client will pass some header items with "None" value in the api request to Cinder API-GW, thus lead to the exception in Cinder API-GW when forwarding the request to the bottom Cinder via requests lib, which lead to the integration failed, and block any patch to be merged. 2.What's need to be fixed: Remove(clean) the invalid header items in the request to the bottom Cinder, in which the python requests lib is used. So that integration test can pass, and make patch being able to be merged. 3.What is the purpose of this patch set: Fix the integration test failure issue casued by strict validity check in http header processing. Change-Id: Iff6d2dd77571180ef9a0cad2171c479be63bd880 Signed-off-by: joehuang <joehuang@huawei.com> |
||
---|---|---|
cmd | ||
devstack | ||
doc/source | ||
etc | ||
releasenotes | ||
specs | ||
tricircle | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.testr.conf | ||
CONTRIBUTING.rst | ||
HACKING.rst | ||
LICENSE | ||
MANIFEST.in | ||
README.rst | ||
requirements.txt | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini |
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.
- Free software: Apache license
- Design documentation: Tricircle Design Blueprint
- Wiki: https://wiki.openstack.org/wiki/tricircle
- Installation with DevStack: https://github.com/openstack/tricircle/blob/master/doc/source/installation.rst
- Documentation: TBD
- Source: https://github.com/openstack/tricircle
- Bugs: http://bugs.launchpad.net/tricircle
- Blueprints: https://launchpad.net/tricircle