84396eb456
1. What is the problem? Originally this patch was committed to the Tricircle and provided dynamic pod binding support. After splitting this feature should be put in Trio2o. So we plan to synchronize this patch from Gerrit to Trio2o. You can find the old patch on Gerrit here[1]. In the Trio2o, each tenant is bound to multiple pods, where it creates various types of resources. However such a binding relationship should be dynamic instead of static. For instance, when some resources in a pod are exhausted, tenant needs to be bound to a new pod in the same AZ. 2. What is the solution to the problem? To deal with the above problem, the Trio2o dynamically binds tenants to pod which has available resources. We call this feature dynamic pod binding, which is explained in the spec[2] in detail. In this patch, we only try to bind a tenant to a pod dynamically, when she tries to create a VM. 3. What the features need to be implemented to the Trio2o to realize the solution? When a tenant creates a VM, the Trio2o first selects all available pods for her. Then by filtering and weighing the pods, the Trio2o selects the most suitable pod for the tenant. Next, the Trio2o queries database for current binding relationship of the tenant. If the tenant is not bound to any pod, we create a new binding relationship, which binds the tenant to the selected pod. If the tenant is already bound to a pod, and the pod is not the one selected by the Trio2o, we update current binding relationship, which binds the tenant to a new pod. If the tenant is already bound to a pod, and the pod is exactly the one selected by the Trio2o, the Trio2o does nothing. [1] https://review.openstack.org/#/c/356187 [2] https://review.openstack.org/#/c/306224 Change-Id: I1c884ce47ace919f732d98ee154bdd59ed22cd74 |
||
|---|---|---|
| cmd | ||
| devstack | ||
| doc/source | ||
| etc | ||
| releasenotes | ||
| specs | ||
| trio2o | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
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.
- Free software: Apache license
- Design documentation: Trio2o Design Blueprint
- Wiki: https://wiki.openstack.org/wiki/trio2o
- Installation with DevStack: https://github.com/openstack/trio2o/blob/master/doc/source/
- Trio2o Admin API documentation: https://github.com/openstack/trio2o/blob/master/doc/source/api_v1.rst
- Source: https://github.com/openstack/trio2o
- Bugs: http://bugs.launchpad.net/trio2o
- Blueprints: https://launchpad.net/trio2o