x
/
trio2o
Code Issues Proposed changes
Trio2o is to provide APIs gateway for multiple OpenStack clouds to act as a single OpenStack cloud.
255 Commits 2 Branches 12 Tags 4.1 MiB
Python 80.6%
Shell 15.1%
reStructuredText 4.3%
Go to file
wenxiong zou bc3c4b1699 [urgent]Adapt new Keystone URL 
1. What is the problem?
Now Keystone uses uwsgi with proxy[1], and this is the default mode
in DevStack. In this case, the original URL with 5000/35357 port can
no longer be accessed, this change will lead to Trio2o gate/check
test always failure if no adaption is made in Trio2o configuration.

2. What is the solution to the problem?
Change Keystone public URL Trio2o uses from
http://host:5000/v3 to http://host/identity and
change Keystone admin URL Trio2o uses from
http://host:35357/v3 to http://host/identity

For tempest test, change http://host:5000/v2.0/
to http://host/identity and change identity version
from 2 to 3 in post_test_hook.sh.
In post_test_hook.sh, add admin_domain_name option.

This patch also fixes a mistake which was hidden before this Keystone
change. While generating Trio2o apache configuration file in our
DevStack script, TRIO2O_BIN in the template is not replaced by
the real value. So the directory access right is not correctly granted.
Before this Keystone change, Keystone apache configuration file will
grant right on the same directory, so we didn't notice this problem.

3. What features need to be implemented to the Trio2o
to realize the solution?
N/A

[1] https://github.com/openstack-dev/devstack/commit/
    6ed53156b6198e69d59d1cf3a3497e96f5b7a870
[2] https://github.com/openstack/neutron/commit/
    46d1a890e700dfa6e921387569f87f793ca4e8e9

Change-Id: I4e1e38b1c07f453fcf2cfed39a16342f235c06b1
 		2017-05-15 19:08:53 +08:00
devstack [urgent]Adapt new Keystone URL 2017-05-15 19:08:53 +08:00
doc/source Enable tempest test 2017-02-06 00:15:28 -05:00
etc Remove networking related code from the Trio2o 2016-11-14 02:12:48 -05:00
releasenotes Merge "Enable release notes translation" 2016-11-17 07:44:19 +00:00
specs Remove networking related code from the Trio2o 2016-11-14 02:12:48 -05:00
trio2o [urgent]Adapt new Keystone URL 2017-05-15 19:08:53 +08:00
.coveragerc Remove networking related code from the Trio2o 2016-11-14 02:12:48 -05:00
.gitignore Change the gate to OpenStack infrastrucure 2015-12-15 12:09:09 +08:00
.gitreview Remove networking related code from the Trio2o 2016-11-14 02:12:48 -05:00
.testr.conf Remove networking related code from the Trio2o 2016-11-14 02:12:48 -05:00
CONTRIBUTING.rst Remove networking related code from the Trio2o 2016-11-14 02:12:48 -05:00
HACKING.rst Remove networking related code from the Trio2o 2016-11-14 02:12:48 -05:00
LICENSE Add source code to Tricircle 2014-09-25 15:56:40 +08:00
README.rst Remove networking related code from the Trio2o 2016-11-14 02:12:48 -05:00
requirements.txt Updated from global requirements 2017-04-07 06:18:25 +00:00
setup.cfg [urgent]Adapt new Keystone URL 2017-05-15 19:08:53 +08:00
setup.py Updated from global requirements 2017-04-07 06:18:25 +00:00
test-requirements.txt Fix the issue in tempest test for volumes 2017-04-10 12:46:05 +08:00
tox.ini Enable tempest test 2017-02-06 00:15:28 -05:00

README.rst

Trio2o

The Trio2o provides an OpenStack API gateway 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 Trio2o and these managed OpenStack instances will use shared KeyStone (with centralized or distributed deployment) or federated KeyStones for identity management.

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

The Trio2o 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.

The end user can see avaialbility zone(AZ) and use AZ to provision VM, Volume, through the Trio2o. One AZ can include many OpenStack instances, the Trio2o 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.