23 Commits

Author SHA1 Message Date
zhiyuan_cai
91137e7eaa Spec for smoke test engine
1. What is the problem
Problems in the current smoke test:
(1) Mix use of bash and python scripts
(2) Resources are not cleaned at the end of the test

2. What is the solution for the problem
A proposed solution is discussed in the spec. The basic idea is
to define tests using YAML and use a engine to parse YAML and
run tests.

3. What features need to be implemented to the Tricircle to
realize the solution
A task engine and a task runner.

Change-Id: Ib7ca2242529e147e9edd6292eec3003967ea83f0
2017-07-10 11:58:54 +08:00
Fangming Liu
17f104d057 Update term "cross OpenStack L2 network"
1. What is the problem
Because Tricircle can work both in multi-region and nova cells v2,
it's more appropriate to replace the term "cross OpenStack L2 network"
with "cross Neutron L2 network".

2. What is the solution for the problem
1) Replace all the occurrences of "cross OpenStack L2 network" with
   "cross Neutron L2 network"
2) Replace all the occurrences of "cross multiple OpenStack instances"
   or "cross pods" with "cross multiple Neutron servers"
3) issue: the configuration "cross_pod_vxlan_mode" keeps unchanged.

3. What the features need to be implemented to the Tricircle to
realize the solution
All documents under directory doc/source and spec/ need to be updated.

Change-Id: I0a4cd9ad0e976fd201aff3e44831c0346d376774
2017-06-28 16:03:26 +08:00
CR_hui
3859f5d94d Move QoS service spec
1. What is the problem
The QoS service will release in Pike, and the spec now in Ocata folder.

2. What is the solution to the problem
Move QoS spec from Ocata folder to Pike folder.

3. What the features need to be implemented to the Tricircle
to realize the solution?
QoS.

Change-Id: I347a3a5460541f4ca69cdca8b8c2633bbcd3a4b4
2017-06-22 16:03:02 +08:00
Jenkins
dab6d071c5 Merge "Networking QoS service spec" 2017-06-14 13:38:48 +00:00
CR_hui
0909e67dee Networking QoS service spec
1. What is the problem
QoS is defined as the ability to guarantee certain network requirements
like bandwidth, latency, jitter, and reliability in order to satisfy a
Service Level Agreement (SLA) between an application provider and end
tenants. Networks or ports in local Neutron can not be associated with
QoS policy automatically yet.

2. What is the solution to the problem
Using asynchronous jobs to complete the automation of QoS policy/rule
in local Neutrons.

3. What the features need to be implemented to the Tricircle
to realize the solution?
QoS.

Change-Id: I8dcce7d35d7fe7283cdeb80d71259d3f3859406b
2017-06-13 08:29:12 +08:00
southeast02
5fe9c5b444 Implement asynchronous job Admin API
1. What is the problem
When XJob receives a job message from service, it will register
the job in database and handle it asynchronously. Tricircle
needs to provide API for admin to query the job status and trigger
failed job if something happens unexpectedly. The detailed work
for XJob Admin APIs is covered in the document[1].

2. What is the solution for the problem
We implement XJob management APIs, they are listed as following:
 *(1) create a job
 *(2) list single job info
 *(3) list all jobs
 *(4) list jobs with filters
 *(5) list all jobs' schemas
 *(6) delete a job
 *(7) redo a job

3. What the features need to be implemented to the Tricircle to
realize the solution
Implement above job operations.

[1] https://review.openstack.org/#/c/438304/

Change-Id: Ibd90e539c9360a0ad7a01eeef185c0dbbee9bb4e
2017-05-03 15:48:55 +08:00
joehuang
098af11b85 Layer-3 Networking multi-NS-with-EW-enabled
1. What is the problem?
Multiple north-south external network topology is supported,
but the east-west networking for local networks across multiple
OpenStack clouds has not been supported yet.

2. What is the solution to the problem?
In multi-region cloud deployment, a requirement is that each
OpenStack cloud provides external network, north-south traffic
is expected to be handled locally for shortest path, and/or
use multiple external networks to help application north-south
traffic redundancy, at the same time east-west networking of
tenant's networks between OpenStack cloud is also needed.
This path will introduce east-west gateway router to address
the east-west networking for local networks in different
OpenStack clouds.

3. What the features need to be implemented to the Tricircle
to realize the solution?
East-west gateway router.

Change-Id: Ie92fc268249371fba86b19e9d070793e24199c91
Signed-off-by: joehuang <joehuang@huawei.com>
2017-04-07 00:24:25 +00:00
Jenkins
4a6a2f62ca Merge "Cross-pod VxLAN network spec" 2017-03-30 01:13:54 +00:00
zhiyuan_cai
6c48f0e4ea Cross-pod VxLAN network spec
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?
The detailed discussion of the proposals to support cross-pod VxLAN
network is covered in this specification.

3. What features need to be implemented to the Tricircle
to realize the solution?
The proposed changes in this specification need to be implemented.

Change-Id: I79b41a63778660bd5a7b6e5e3d66ce0bd394e9af
2017-03-23 17:05:12 +08:00
Dongfeng Huang
9a37c81476 spec on asynchronous job management
1. What is the problem
When XJob receives a job message from service, it will register
the job in database and handle it asynchronously. Tricircle
need to provide API for users to query the job status and trigger
failed job if something happens unexpectedly. This patch provides
asynchronous job management specification, then we will develop
relevant API to manage the job according to this specification.

2. What is the solution for the problem
The new features functioning as job management APIs are covered
in this specification.

3. What the features need to be implemented to the Tricircle to
realize the solution
These asynchronous job management APIs in this specification need
to be implemented.

Change-Id: I58df65b042a8866c4d8d7f5a65a3f85bcf43b62b
2017-03-20 14:50:53 +08:00
Dongfeng Huang
eb084c2d0f Fix the grammar errors reported in the doc
1. What is the problem
In the enhance-xjob-reliability.rst, there are some
grammar errors and unnecessary characters. They are
reported as a bug(please see it at the bottom).

2. What is the solution for the problem
Correct the grammar errors and remove the unnecessary
characters.

3. What the features need to be implemented to the Tricircle to
realize the solution
None.

Change-Id: If5a1540ce2ac4f7e416ee3070b558346a578fe1d
Closes-Bug: #1667869
2017-02-25 10:41:56 +08:00
xiulin yin
2d6cae8097 Change network type shared_vlan name to vlan
1. What is the problem
shared_vlan's concept is to create a network spanning into multiple
OpenStack with same vlan segment, but when create a network which only
resides in one region and the network type is vlan, we have to specify
the physical network type as shared_vlan, otherwise no other way to
create a vlan network in local Neutron.

2. What is the solution to the problem
Just use vlan as the physical network type, and use
availability_zone_hints to limit where the network will reside.

3. What the features need to be implemented to the Tricircle
No new features

Change-Id: Ib3f110e2281eff2997752debda319da282c3e3ad
2017-01-17 10:51:24 +08:00
Jenkins
fbcb71ed86 Merge "Enhance XJob reliability spec" 2017-01-07 07:05:30 +00:00
Dongfeng Huang
d65601a4ff Clean useless tables in Tricircle after splitting
1. What is the problem?
Tricircle now is dedicated for networking automation across Neutron. Some
tables used in APIs gateway should be removed, like aggregation table, pod
binding table, etc. They should not reside in the Tricircle any more. Other
tables containing old meanings but are still in use should be renamed for
better understanding. We can see the blueprint[1] for further explanation.

2. What is the solution to the problem?
The data models, tables and APIs about aggregation, pod binding, etc. should
be removed. After the pod binding table is removed, the az_hint used for
external network creation is hard to match. So special handle needs to be
implemented. Other tables will have vague meaning after this splitting, but
they still take effective in the Tricircle, So they should be renamed for
better understanding. What's more, the pod_name in the pod table is renamed
to region_name, which coordinates better with its availability zone.

  1)Tables to be removed:
    *aggregates
    *aggregate_metadata
    *instance_types
    *instance_type_projects
    *instance_type_extra_specs
    *key_pairs
    *pod_binding
  2)Tables need to be renamed:
    *cascaded_pod_service_configuration (new name: cached_endpoints)
    *cascaded_pods (new name: pods)
    *cascaded_pods_resource_routing (new name: resource_routings)
    *job (new name: async_jobs)

3. What the features need to be implemented to the Tricircle to realize
the solution?
After the pod binding table is removed, the az_hint used for external
network creation is hard to match. New features will be implemented to solve
this problem.

[1] https://blueprints.launchpad.net/tricircle/+spec/clean-legacy-tables
Change-Id: I025b4fb48c70abf424bd458fac0dc888e5fa19fd
2017-01-05 09:53:45 +08:00
zhiyuan_cai
2161a18f02 Enhance XJob reliability spec
1. What is the problem?
Currently we use cast method to trigger XJob daemon which we have
risk to lose jobs.

2. What is the solution to the problem?
Determine a solution to improve the reliability of XJob daemon. The
detailed discussion of the problems and the proposals to solve the
problems are covered in this specification.

3. What the features need to be implemented to the Tricircle
to realize the solution?
The proposed changes in this specification needs to be implemented.

Change-Id: Idf7ec52098393d668d1425a79807b235a1fc9960
2017-01-04 17:14:00 +08:00
Dongfeng Huang
d1bc1f4eb8 spec on legacy tables clean work
1. What is the problem?
After the Tricircle narrowed its scope to networking automation across Neutron
servers, many table are deprecated, therefore they should be removed. Other
tables that still exist in the Tricircle need to be renamed for better
understanding.

2. What is the solution to the problem?
The detailed description of the problems and the proposals to solve the
problems will be covered in this specification.

3. What the features need to be implemented to the Tricircle to realize
the solution?
The new features discussed in this specification needs to be implemented.

Change-Id: Idf61ecb30f54e40fde283ee5f3278b2f4b429f66
2016-12-29 18:38:00 +08:00
Jenkins
966256c376 Merge "Layer-3 networking and combined bridge network spec" 2016-12-21 04:34:43 +00:00
Cady_Chen
5c69e14703 Fix typos
1. What is the problem?
There were some typos in this module, which should be modified.

2. What is the solution to the problem?
This change modifies the spelling mistakes.

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

Change-Id: I04bf779e371adfc2816a549fc95fcaa44cd8d6d0
2016-12-16 11:40:06 +08:00
zhiyuan_cai
f423b76a83 Layer-3 networking and combined bridge network spec
1. What is the problem
The current implementation of bridge networks has some problems
when supporting DVR and shared VxLan network.

2. What is the solution to the problem
The detailed discussion of the problems and the proposals to
solve the problems will be covered in this specification. This
specification will also discuss the proposed and supported
cross-OpenStack layer-3 networking model.

3. What the features need to be implemented to the Tricircle
   to realize the solution
The proposal to combine bridge networks discussed in this
specification needs to be implemented.

Change-Id: Ib0c3d8c31de5c2f9c1c5b08a222971ea628cc3c1
2016-12-13 15:12:59 +08:00
zhiyuan_cai
32fef062d7 Specification for local Neutron plugin
1. What is the problem
Part of the networking automation functionality is implemented
in the Nova-APIGW, which bring coupling between Neutron and Nova
servers. Users must deploy Nova-APIGW if they want to use the
networking automation function, which is not flexible.

2. What is the solution to the problem
Move the process of networking automation from the Nova-APIGW
to local Neutron plugin. This specification covers the detailed
introduction and discussion of this plugin.

3. What the features need to be implemented to the Tricircle
   to realize the solution
The local Neutron plugin discussed in this specification needs
to be implemented.

Change-Id: I6450ab0d2103eb8fd6fa8869ae80376a37ae371a
2016-09-29 09:32:01 +08:00
Jenkins
828f55287e Merge "Add cross-pod L2 Networking spec file" 2016-06-17 01:30:39 +00:00
XiongQiu
8a9a07db86 Add cross-pod L2 Networking spec file
1. What is the problem?
In the Tricircle, the cross pod L2 networking automation is
established after the VM is plugged into. The simplest way to
stretch one L2 network across multiple OpenStack instances is to
use a same VLAN network, but there is a lot of limitation: the
number of VLAN segment is limited, the VLAN network itself is not
good to spread across multiple sites, although you can use some
gateways to do so. But there are so many tenants in the cloud, and
new tenants could be added into the cloud dynamically, fixed physical
network configuration for dynamic tenant networking is hard to manage.

2. What is the solution to the problem?
To deal with the above problem, flexible tenant level L2 networking
automation across multiple OpenStack instances in one site or in
multiple sites is needed in the Tricirlce.

3. What the features need to be implemented to the Tricircle to
realize the solution?
To implement the features that networking automation supports more
than one bottom pod in AZ or multiple AZs for different use cases
in the Tricircle

Blueprint: https://blueprints.launchpad.net/tricircle/+spec/cross-site-connectivity
Change-Id: I616048c13d03f48aa16d9ff48572b0d5a49d6fb4
2016-06-16 22:05:54 +08:00
Yipei Niu
a1602f7e5e Add specification for dynamic pod binding
1. What is the problem?
In production clouds, each availability zone (AZ) is built by modularized
OpenStack instances. Each OpenStack instance acts as a pod. One AZ
consists of multiple pods. Among the pods within an AZ, they are
classified into different categories for different proposes, for instance,
general propose, CAD modeling and so on. Each tenant is bound to one pod,
where it creates various types of resources. However such a binding
relationship should be dynamic instead of static. For instance when
some resources in the pod are exhausted, tenant needs to be bound to a
new pod in same AZ.

2. What is the solution to the problem?
To deal with the above problem, the Tricircle dynamically bind tenants
to pod which has available resources. We call this feature dynamic pod
binding

3. What the features need to be implemented to the Tricircle to realize
the solution?
To realize dynamic pod binding, the following features need to be
implemented in the Tricircle.
1) To collect the usage in pod daily to evaluate whether the threshold
is reached or not.
2) To filter and weigh all the available pods for cloud tenants to bind
a tenant to a proper pod.
3) To manage and maintain all the active and historical binding
relationship.

This spec explains how Tricircle binds pods to tenants dynamically
in detail.

Blueprint: https://blueprints.launchpad.net/tricircle/+spec/dynamic-pod-binding

Change-Id: Ib429a59d3d216e578f9c451d84c1fe9a333cf050
2016-06-15 20:55:59 +08:00