da3ed5a9f6
1. What is the problem Network type framework has been merged but only the local network type is supported currently, so cross-pod l2 networking is still not available. 2. What is the solution to the problem At the first step, we support the simplest shared vlan network type. VMs in different pods are hosted in the network of its own pod with the same vlan ID and are connected with physical switches. 3. What the features need to be implemented to the Tricircle to realize the solution (1) A shared vlan type driver is added. (2) During the process of VM creation, if Nova_apigw finds that the required network is shared vlan type, it uses all the segment information of the network to form a network creation request and sends it to the Neutron server in the bottom pod with admin token. (3) The creation of bridge network for cross-pod l3 networking directly uses shared vlan type driver, no longer requires extra codes to allocate segments. To fully complete functional shared vlan network type, it's necessary to add functionality of port creation for gateway in each pod. But this patch set does not cover this functionality because of complexities. Change-Id: I8dd75d51fb74340c03d44e007b217f70d1a12d66
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