1. What is the problem?
Tricircle now don't support QoS service, we should add QoS
servicesupporting.
2. What is the solution to the problem?
We implement Tricircle QoS service by inherit neutron QoS plugin.
For QoS automation deployment in local, we should implement QoS xjob
jobs.
Change-Id: Ifbf453b57f7e18919318e1dae2ca2849e149a29b
Signed-off-by: xiaohan zhang <zhangxiaohan@szzt.com.cn>
1. What is the problem
Smoke test engine has been implemented[1] and tests for single
north-south gateway topology and multiple north-south gateway
topology have been added. But we still lack test for service
function chain.
2. What is the solution for the problem
Define service function chain related test using YAML file.
3. What features need to be implemented to the Tricircle to
realize the solution
N/A
[1] https://review.openstack.org/#/c/477500/
Implements: blueprint smoke-test-engine
Change-Id: I02a9bc8a6c7cebe166a633764e424e3812a9a042
1. What is the problem
Smoke test engine has been implemented[1] and tests for single
north-south gateway topology and multiple north-south gateway
topology have been added. But we still lack test for trunk.
2. What is the solution for the problem
Define trunk related test using YAML file.
3. What features need to be implemented to the Tricircle to
realize the solution
N/A
[1] https://review.openstack.org/#/c/477500/
Implements: blueprint smoke-test-engine
Change-Id: If9df9983350ea442dab6106cb58d49590c0677b1
1. What is the problem
We try to figure out a way to integrate Tricircle with Nova cell v2.
2. What is the solution for the problem
The basic idea is to start a local Neutron server for each cell. Nova-
compute in each cell is configured to talk to local Neutron server in
the same cell. All local Neutron servers are configured to talk to the
very one Nova-API.
Currently DevStack doesn't support multi-cell deployment, so we try to
deploy it with our own plugin. In node1, Nova services are started as
before, but we change the region of Nova-API, Glance-API and placement-API
from RegionOne to CentralRegion. Local Neutron server is also configured
to talk to Nova-API in CentralRegion. In node2, Nova-API is enabled at
first, since we need DevStack to help us create the related database.
After the DevStack start in the node2, we manually stop Nova-API and
Nova-scheduler in node2.
One document discussing the detailed setup and trouble shooting steps
is added.
3. What features need to be implemented to the Tricircle to
realize the solution
Tricircle can work with Nova cell v2.
Change-Id: I6ba8e1022d83f40df36464abfdd7b4844673b24d
1. What is the problem?
The python-tricircleclient has been included as part of the OpenStack
official repositories[1] but their integration hasn't been done in
Devstack.
[1] https://review.openstack.org/#/c/426419/
2. What is the solution to the problem?
Add the required instructions to control the installation of the
client in the plugin.sh script. Usually those instructions have a
standard format which needs to be follow.
3. What the features need to be implemented to the Tricircle
to realize the solution?
None
Change-Id: I0f2df46316f191c443b9192875868d4c7be96c1b
1. What is the problem
Flat network type is commonly used as the external network type, but
currently users can not create a flat external network via Tricircle.
2. What is the solution for the problem
Support flat network type.
3. What features need to be implemented to the Tricircle to
realize the solution
(1) A new type driver for flat network is added.
(2) Release note is added
(3) Related documents are updated
Change-Id: I148e1102510dda96a9fcd8a4b76de09cd802833c
1. What is the problem
Currently Tricircle Admin API is running through python command
line and will start oslo_service wsgi server directly.
The community has set a community wide goal in Pike cycle:
"Control Plane API endpoints deployment via WSGI"
https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
Completion Criteria
a). Provide WSGI application script file(s) (e.g. to be used by web
server). There shouldn't be any web server restriction and the
application could be deploying to any web server that support
WSGI applications.
b). Switch devstack jobs to deploy control-plane API services in
WSGI with Apache. Usage of Apache is already the default in Devstack,
let's keep using it for consistency unless there is some efforts to
support another web server but this is not the case at this time.
2. What is the solution for the problem
The first step is to finish these two goals:
a). Provide WSGI application script file
b). Update devstack related script in Tricircle to use Apache as
the web server.
The second step will clean and update other documentation
accordingly
3. What the features need to be implemented to the Tricircle to
realize the solution
No new feature delivered to end user.
Change-Id: I828f2d846725d18bb4a66a5d357c717e6b7d28bb
Signed-off-by: joehuang <joehuang@huawei.com>
1. What is the problem?
VLAN network has some restrictions that VxLAN network doesn't have.
For more flexible networking deployment, we consider supporting
cross-pod VxLAN network.
2. What is the solution to the problem?
We are going to use shadow agent/port mechanism to synchronize VTEP
information and make cross-pod VxLAN networking available, as discussed
in the specification document[1].
3. What the features need to be implemented to the Tricircle
to realize the solution?
This is the first patch for cross-pod VxLAN networking support, which
introduces the following changes:
(1) A new type driver for VxLAN network is added
(2) During processing update request from nova, local plugin populates
agent info in the update body and sends update request to central
neutron
(3) Central neutron extracts agent info from request body and registers
shadow agent in Tricircle database
(4) During processing create request, if agent info is set in the
binding:profile in the create body, local plugin creates or updates
shadow agent before invoking real core plugin
(5) During processing update request, if "force_up" is set in the
binding:profile in the update body, local plugin updates the port
status to active to trigger l2 population
[1] https://review.openstack.org/#/c/429155/
Change-Id: I2e2a651887320e1345f6904393422c5a9a3d0827
1. What is the problem
After manual installation guide is updated in this patch[1], cmd
folder is no longer refered to
2. What is the solution to the problem
Remove cmd folder, also remove two setting options in devstack/settings
3. What the features need to be implemented to the Tricircle
No new features
[1] https://review.openstack.org/#/c/432838/
Change-Id: Ia6bc07ac868f7dcbe46f49f27c602780ee76ecd3
1.What is the problem?
Devstack plugin only supports the first region installation,
for the second region installation with Tricircle local plugin,
need to install the tricircle package manually (please refer
to the multi-pod-installation-devstack.rst in doc/source).
2.What is the solution to the problem?
If we want to support multi-region gate/check test job
(https://blueprints.launchpad.net/tricircle/+spec/multi-region-job-for-gate-and-check-test),
the second region in the gate/check job can only be installed
through devstack plugin and local.conf. So we have to improve
the devstack plugin to support the second region installation.
Tricircle AdminAPI and XJob shouldn't be started in the second
region, there is no need to generate database schema
for the second region too. only the plugin needs to be installed
and configured in local Neutron. So TRICIRCLE_START_SERVICES is
introduced in devstack local.conf. The TRICIRCLE_START_SERVICES
variable needs to be enabled in the first region and disabled
in the second one.
At the same time, remove the variable Q_ENABLE_TRICIRCLE judgement
and configuration, if the Tricircle DevStack plugin is enabled,
that means the plugin itself will run by default.
3.What the features need to be implemented to the Tricircle
to realize the solution?
No new features.
Change-Id: Ib66a22f9e4889d131e5e481e9dec98efca5ed6fe
Signed-off-by: joehuang <joehuang@huawei.com>
1. What is the problem
As discussed in the feature specification[1], we are going to
move the process of networking automation from the Nova-APIGW
to Neutron server.
2. What is the solution to the problem
Implement a new Neutron core plugin which runs in local Neutron
server to finish the networking automation process. Also, the
original Neutron core plugin is renamed as central plugin and
needs some changes to work with local plugin.
3. What the features need to be implemented to the Tricircle
to realize the solution
With this patch, users can boot a virtual machine directly via
the local Nova server. But security group support is not covered.
DevStack script and local.conf sample are also updated.
[1] https://github.com/openstack/tricircle/blob/master/specs/ocata/local-neutron-plugin.rst
Change-Id: I6a3dc5e9af395e3035a7d218264a08b6313a248d
The statless design was developed in the experiment branch, the experiment
shows advantage in removing the status synchronization, uuid mapping
compared to the stateful design, and also fully reduce the coupling with
OpenStack services like Nova, Cinder. The overhead query latency for
resources also acceptable. It's time to move the statless design to the
master branch
BP: https://blueprints.launchpad.net/tricircle/+spec/implement-stateless
Change-Id: I51bbb60dc07da5b2e79f25e02209aa2eb72711ac
Signed-off-by: Chaoyi Huang <joehuang@huawei.com>
Initial patch for compute proxy, now we can boot a vm and the
RPC request will be captured by dispatcher then sent to proxy.
Change-Id: I361d18e0b87ece3db113f6549f2b3c9bf50e1006
Implement site create RPC. Now tricircle api can utilize RPC
to notify cascade service to start rpc server for new site.
Partially implements: blueprint implement-api
Ref: https://blueprints.launchpad.net/tricircle/+spec/implement-api
Change-Id: I73879a84d31b5ac9004cfe3f18cb9a984d53099c
This is the base implementation. It adds all the devstack boilerplate
and connects to the network plugins' requests.
Change-Id: Ibd61153e755e1c218503b0671c242ff50b5ebdc8