361f7f7a27
1. What is the problem Shared vlan type driver has been merged, so we can run two VMs in the same network but across two pods. However if we attach a network to the router, the tricircle plugin still check if the network is bound to one AZ, so one network cannot cross different pods if we are going to attach it to a router. 2. What is the solution to the problem The reason we require network to be bound to AZ is that when the network is attaching the one router, we know where to create the bottom network resources. To support l3 networking in shared vlan network, we need to remove this restriction. In the previous patches[1, 2], we have already move bottom router setup to an asynchronouse job, so we just remove the AZ restriction and make the tricircle plugin and the nova_apigw to use the job. Floating ip association and disassociation are also moved to bottom router setup job. 3. What the features need to be implemented to the Tricircle to realize the solution Now network can be attached to a router without specifying AZ, so l3 networking can work with across-pod network. [1] https://review.openstack.org/#/c/343568/ [2] https://review.openstack.org/#/c/345863/ Change-Id: I9aaf908a5de55575d63533f1574a0a6edb3c66b8 |
||
---|---|---|
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