RETIRED, Tricircle is to provide networking automation across Neutron.
Go to file
songbaisen c6ddbb39b7 spec for resource deleting
1. What is the problem?
During the deletion of a network which is mapped to several local networks, if
the local neutron server receives a network-get request, it will bring some
conflict operations. For example, we delete local networks before deleting
central network. If a "get_network" request comes to a local neutron server
after the local network is completely deleted in that region, if central
network is still there (assuming it takes certain time to delete all local
networks), Tricircle will also query central neutron and the deleted local
network will be recreated.

2. What is the solution to the problem?
The solution to resource deleting is covered in this specification.

3. What the features to be implemented in the Tricircle
to realize the solution?
No new features.

Change-Id: I4f29ee9f214242262bffc616dc60c8fdde76a6f6
Signed-off-by: song baisen <songbaisen@szzt.com.cn>
Co-Authored-By: CR_hui <CR_hui@126.com>
2018-01-24 09:42:16 +08:00
devstack Merge "QoS implementation(Part1: Qos Plugin)" 2017-11-28 06:02:34 +00:00
doc/source Installation and configuration guide for lbaas 2017-11-23 10:46:36 +08:00
etc Use DocumentedRuleDefault instead of RuleDefault 2017-10-18 01:02:55 +00:00
releasenotes Merge "QoS implementation(Part1: Qos Plugin)" 2017-11-28 06:02:34 +00:00
specs spec for resource deleting 2018-01-24 09:42:16 +08:00
tricircle Merge "QoS implementation(Part1: Qos Plugin)" 2017-11-28 06:02:34 +00:00
.coveragerc Align project files structure with cookiecutter template 2016-07-05 15:08:41 +08:00
.gitignore Use DocumentedRuleDefault instead of RuleDefault 2017-10-18 01:02:55 +00:00
.gitreview Update .gitreview for new namespace 2015-10-17 22:41:25 +00:00
.testr.conf Add the Tricircle tempest plugin with a sample test case 2016-06-08 12:51:38 +08:00
CONTRIBUTING.rst Align project files structure with cookiecutter template 2016-07-05 15:08:41 +08:00
HACKING.rst Update the documentation link for doc migration 2017-07-19 08:19:40 +00:00
LICENSE Add source code to Tricircle 2014-09-25 15:56:40 +08:00
README.rst Change links in README to the newest addresses 2017-08-18 11:31:37 +08:00
index.rst [doc-migration] Reorganize the Tricircle doc/source folder 2017-07-26 19:47:05 +08:00
requirements.txt Updated from global requirements 2017-12-05 03:39:22 +00:00
setup.cfg QoS implementation(Part1: Qos Plugin) 2017-11-24 16:01:04 +08:00
setup.py Updated from global requirements 2017-03-03 23:01:07 +00:00
test-requirements.txt Updated from global requirements 2017-11-16 11:30:07 +00:00
tox.ini Enable some off-by-default checks 2017-11-22 19:09:41 +08:00

README.rst

Team and repository tags

image

Tricircle

The purpose of the Tricircle project is to provide networking automation across Neutron servers in multi-region OpenStack clouds deployment.

Each OpenStack cloud includes its own Nova, Cinder and Neutron, the Neutron servers in these OpenStack clouds are called local Neuron servers, all these local Neutron servers will be configured with the Tricircle Local Neutron Plugin. A separate Neutron server will be installed and run standalone as the coordinator of networking automation across local Neutron servers, this Neutron server will be configured with the Tricircle Central Neutron Plugin, and is called central Neutron server.

Leverage the Tricircle Central Neutron Plugin and the Tricircle Local Neutron Plugin configured in these Neutron servers, the Tricircle can ensure the IP address pool, IP/MAC address allocation and network segment allocation being managed globally without conflict, and the Tricircle handles tenant oriented data link layer(Layer2) or network layer(Layer3) networking automation across local Neutron servers, resources like VMs, bare metal or containers of the tenant can communicate with each other via Layer2 or Layer3, no matter in which OpenStack cloud these resources are running on.

Note: There are some our own definitions of Layer2/Layer3 networking across Neutron. To make sure what they are, please read our design documentation, especially "6.5 L2 Networking across Neutron". The wiki and design documentation are linked below.

The Tricircle and multi-region OpenStack clouds will use shared KeyStone(with centralized or distributed deployment) or federated KeyStones.

The Tricircle source code is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file.