Commit Graph

18 Commits

Author SHA1 Message Date
zhangxiaohan
db679ef7cb QoS implementation(Part1: Qos Plugin)
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>
2017-11-24 16:01:04 +08:00
zhiyuan_cai
8af1e2e08b Add service function chaining smoke test
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
2017-07-26 10:27:02 +08:00
zhiyuan_cai
eb2662b33e Add trunk smoke test
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
2017-07-25 09:23:40 +08:00
zhiyuan_cai
6f9928bf8d Work with cell v2
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
2017-05-27 16:42:28 +08:00
Victor Morales
5f90f95291 Include tricircleclient installation
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
2017-05-18 09:28:15 -05:00
zhiyuan_cai
ee008cae6b Enable flat network type support
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
2017-04-11 17:30:31 +08:00
joehuang
6eb93e844d Support WSGI deployment for Tricircle Admin API(part1)
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>
2017-03-25 05:17:37 -04:00
zhiyuan_cai
bb73104ca2 Shared VxLAN (Part1: shadow agent)
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
2017-03-13 14:02:40 +08:00
zhiyuan_cai
503ab1a016 Remove cmd folder
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
2017-02-14 17:14:54 +08:00
joehuang
8616eb5fa4 Update devstack plugin to support multi-region installation
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>
2017-01-11 21:52:12 -05:00
zhiyuan_cai
b0789882eb Central and local plugin (part 1, base)
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
2016-10-10 22:58:00 -04:00
Chaoyi Huang
81b45f2c1d Move statless design from experiment to master branch
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>
2016-01-14 12:56:57 +08:00
zhiyuan_cai
57f0ddbf91 Proxy for compute
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
2015-12-02 09:41:13 +08:00
zhiyuan_cai
fd5e79451e Site create RPC
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
2015-11-20 17:36:21 +08:00
venkatamahesh
a5fa51f6e4 Change the repository from stackforge to openstack
Change-Id: I82231a55537655aab369be3a14e36e80d23dfc11
2015-10-18 15:58:02 +05:30
joehuang
e94e98ad4a Add cascade service REST api framework
Fisrt patch to implement the REST api framework based on pecan, with keystone authentication integrated.
No resources implemented in the first patch

Change-Id: I8bff9f934fbba183f0b0e7b540fa755965c229a0
implements: blueprint: https://blueprints.launchpad.net/tricircle/+spec/implement-rest-api-framework
2015-09-10 11:30:23 +08:00
Saggi Mizrahi
c5d6976471 cascade_service framework
This is the base implementation. It adds all the devstack boilerplate
and connects to the network plugins' requests.

Change-Id: Ibd61153e755e1c218503b0671c242ff50b5ebdc8
2015-08-05 14:49:25 +03:00
Saggi Mizrahi
2013bc8642 Base devstack install script first patch only handle networking
Change-Id: Ic9962d261d4eb0c6fc2c68206b4b6253ccf8f561
2015-08-05 14:49:24 +03:00