afbf8efbce
1. What is the problem? In the Tricircle, 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 same AZ. 2. What is the solution to the problem? To deal with the above problem, the Tricircle dynamically bind tenants to pod which has available resources. We call this feature dynamic pod binding, which is explained in https://review.openstack.org/#/c/306224/ in detail. In this patch, we only try to binds a tenant to a pod dynamically, when she tries to create a VM. 3. What the features need to be implemented to the Tricircle to realize the solution? When a tenant creates a VM, the Tricircle first selects all available pods for her. Then by filtering and weighing the pods, the Tricircle selects the most suitable pod for the tenant. Next, the Tricircle query 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 pod selected by the Tricircle, 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 pod selected by the Tricircle, the Tricircle does noting. Change-Id: I3972e6799f78da6ec35be556487f79b1234731b8 |
||
---|---|---|
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
- Tricircle Admin API documentation: https://github.com/openstack/tricircle/blob/master/doc/source/api_v1.rst
- Source: https://github.com/openstack/tricircle
- Bugs: http://bugs.launchpad.net/tricircle
- Blueprints: https://launchpad.net/tricircle