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
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
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
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
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
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>
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
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
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
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
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
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
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
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
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
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
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
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
