5f0978ef7b
1. What is the problem Our current mechanism to handle dhcp port creation is that we first create the top dhcp port, then use the allocated ip to create the bottom dhcp port. If we get an "IpAddressInUse" error, meaning that bottom dhcp agent has already created the dhcp port with the same ip, we just reuse the port; otherwise, we successfully create the bottom dhcp port, we remove other dhcp ports with different ips, so dhcp agent can be notified and use the bottom dhcp port we create. However, we find that this mechanism doesn't work in the following situation. Dhcp agent may create the bottom dhcp port after we do the check about whether other dhcp ports exist, so we don't remove the dhcp port created by dhcp agent, thus we end up with two bottom dhcp ports, one is created by dhcp agent, one is created by us. 2. What is the solution to the problem Create bottom subnet with dhcp disabled, so dhcp agent will not be scheduled, then create bottom dhcp port and update bottom subnet to enable dhcp. Finding that there is already a reserved dhcp port, dhcp agent will not create another dhcp port and directly use the existing one. 3. What the features need to be implemented to the Tricircle to realize the solution No new feature introuduced. Change-Id: I8bb8622b34b709edef230d1f1c985e3fabd5adb0
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