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>
The policy-and-docs-in-code Queens goal outlines the work required
for projects to move policy into code and document the operations
and defaults.
This commit replaces occurrences of RuleDefault with
DocumentedRuleDefault where appropriate, which requires additional
attributes when used that supply more documentation in rendered
policy files.
Using DocumentedRuleDefault produces more descriptive generated
policy descriptons in 'configuration' section of tricircle docs.
Change-Id: I5be169e996066ff66d165731cf2bf12aaff38fd4
1. What is the problem
OpenStack doc team is doing OpenStack manuals project migraion, we
need to finish some required actions.
2. What is the solution for the problem
As described in the specification[1], we need to enable warning-is-
error in setup.cfg and fix errors if any.
3. What features need to be implemented to the Tricircle to
realize the solution
N/A
[1] http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html
Change-Id: I27481d9d28875837c0bbb4aec89c42aa07027135
1. What is the problem
Tricircle does not support Service Function Chain
2. What is the solution to the problem
Add Service Function Chain support
3. What the features need to be implemented to the Tricircle
Add create, delete support
Change-Id: I4bbe169040c17d202410bb5a649aca4df8464c3c
* The tricircle projects contains the skeletion of tempest plugin and
there is nothing implemented with in the plugin and the existing plugin
extension is breaking the tempest cli. So it is better to completely
remove the plugin.
* In future, if we need tempest plugin for tricircle, we need to implement
in a seperate repo.
Change-Id: I2dbf532ae9b33035187f92b9092af6d26eaba338
Closes-Bug: #1693546
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
The gating on python 3.4 is restricted to <= Mitaka. This is due to
the change from Ubuntu Trusty to Xenial, where only python3.5 is
available. There is no need to continue to keep these settings.
2. What is the solution to the problem
Remove py34 support
3. What the features need to be implemented to the Tricircle
No new features
Change-Id: Id0652300c2b824cc3f6d6ae9453b8bc818fdaba1
1. What is the problem
Current python language classifier in setup.cfg doesn't support python 3.5
2. What is the solution to the problem
Adding python 3.5 support to classifier in setup.cfg
3. What the features need to be implemented to the Tricircle
N/A
Change-Id: I7e89db2638c0aa16e5cbebe116f03f438b246673
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?
There is no direct way to call tricircle commands. In consequence,
every command has to be consumed thru python interpreter.
e. g. python cmd/manage.py etc/api.conf
2. What is the solution to the problem?
The solution is to list the new commands in the pbr configuration
file. The pdr configuration requires a valid python modules, but
given that they have implementated in *cmd* directory(instead of
*tricircle/cmd*) is required to move them. As initial phase
commands will be copied, once there is no reference to the old ones
it's possible to proceed to deprecate them.
3. What the features need to be implemented to the Tricircle to
realize the solution?
Replace calls to duplicate module and deprecate the old one.
Change-Id: I6a27d990803e928151ca424f47564b6626c8e99b
1. What is the problem
Current home-page's link in setup.cfg point to the wrong one.
2. What is the solution to the problem
Using the right link for developer to replace current one.
3. What the features need to be implemented to the Tricircle
N/A
Change-Id: Idd828cdd26a94651c4e59a7b317a9287f0daa895
1. What is the problem?
Nova API-GW and Cinder API-GW code are still in the repository of
the Tricircle project.
2. What is the solution to the problem?
According to the blueprint for the Tricircle splitting:
https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron
Nova API-GW and Cinder API-GW related code should be removed from
the repository of the Tricircle project.
3. What the features need to be implemented to the Tricircle to realize
the solution?
No new features.
Change-Id: I152bab9c0a7a114f0361a69a3ab2d7037731434f
1. What is the problem?
In the Tricircle, each tenant is bound to multiple pods,
where it creates various types of resources. However such a binding
relationship should be dynamic instead of static. For instance when
some resources in a 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, which is explained in https://review.openstack.org/#/c/306224/
in detail. In this patch, we only try to binds a tenant to a pod
dynamically, when she tries to create a VM.
3. What the features need to be implemented to the Tricircle to realize
the solution?
When a tenant creates a VM, the Tricircle first selects all available
pods for her. Then by filtering and weighing the pods, the Tricircle
selects the most suitable pod for the tenant. Next, the Tricircle query
database for current binding relationship of the tenant. If the tenant
is not bound to any pod, we create a new binding relationship, which
binds the tenant to the selected pod. If the tenant is already bound to
a pod, and the pod is not the pod selected by the Tricircle, we update
current binding relationship, which binds the tenant to a new pod. If
the tenant is already bound to a pod, and the pod is exactly the pod
selected by the Tricircle, the Tricircle does noting.
Change-Id: I3972e6799f78da6ec35be556487f79b1234731b8
Python 3.3 support would be dropped by
Infra team from mitaka,CI would no longer be testing it,
so projects should drop it also.
Change-Id: I3bf594f925341a74ac06aa35df3430c0f77600ec
1. What is the problem
Network type framework has been merged but only the local network
type is supported currently, so cross-pod l2 networking is still
not available.
2. What is the solution to the problem
At the first step, we support the simplest shared vlan network
type. VMs in different pods are hosted in the network of its own
pod with the same vlan ID and are connected with physical switches.
3. What the features need to be implemented to the Tricircle
to realize the solution
(1) A shared vlan type driver is added.
(2) During the process of VM creation, if Nova_apigw finds that
the required network is shared vlan type, it uses all the segment
information of the network to form a network creation request and
sends it to the Neutron server in the bottom pod with admin token.
(3) The creation of bridge network for cross-pod l3 networking
directly uses shared vlan type driver, no longer requires extra
codes to allocate segments.
To fully complete functional shared vlan network type, it's necessary
to add functionality of port creation for gateway in each pod. But this
patch set does not cover this functionality because of complexities.
Change-Id: I8dd75d51fb74340c03d44e007b217f70d1a12d66
1.What is the problem
An OpenStack project should be created based on the template
generated by cookiecutter: http://docs.openstack.org/infra/manual/creators.html#preparing-a-new-git-repository-using-cookiecutter
There are some files missing in the Tricircle compared to
the files generated by cookiecutter template.
2.What's need to be fixed:
This patch sets is to amend this missing files.
Moreover, README.md was renamed to README.rst, and the installation
part with devstack was moved to doc/source/installation.rst according
to the cookiecutter generated template. The README.rst in the
Tricircle root folder was updated accordingly, and only the description
of the Tricircle was remained.
3.What is the purpose of this patch set:
To make the Tricircle follow other OpenStack project folder structure
template which could be generated by cookiecutter to keep consistency.
Change-Id: I65d4c376a87eccded12bd3f08bcd9ee89def95d4
Signed-off-by: Chaoyi Huang <joehuang@huawei.com>
1. What is the problem
In the current implementation of the Tricircle plugin for neutron,
network type is not supported so users cannot create networks
with network type specified. In the specification of cross-pod
l2 networking feature[1], we decide to support several network
types like local, shared VLAN, shared VxLAN, etc, the first step
is to make the Tricircle plugin be aware of network type.
2. What is the solution to the problem
Handle network type in the Tricircle plugin for neutron.
3. What the features need to be implemented to the Tricircle
to realize the solution
In this patch, we add a framework to load type driver which
processes different network type. The framework is based on
neutron ML2 implemenation, we inherit the ML2 type manager and
create a new Tricircle type manager. Also the Tricircle plugin
is modified to extract network type parameter from request and
insert network type information to response.
[1] https://github.com/openstack/tricircle/blob/master/specs/cross-pod-l2-networking.rst
Change-Id: Ida9b88df6113db46e637a7841ce5c1adaf651eba
1.What is the purpose of this patch set?
The Tricircle project doesn't provide integration test yet.
To achieve integration test, the Tricircle needs to provide
Tempest plugin, so that the integration test job could
be configured in CI pipeline.
Tempest is a set of integration tests to be run against a live
OpenStack cluster:
http://docs.openstack.org/developer/tempest/overview.html
Tempest has an external test plugin interface which enables project
to integrate an external test suite as part of a tempest run.
http://docs.openstack.org/developer/tempest/plugin.html
This patch set is to create the Tricircle tempest plugin with a sample
test case. And main purpose of the patch set is to make tempest enable
to discover the Tricircle tempest plugin and its test case.
2.What is the benefit of this patch set for the Tricircle project?
Make the Tricircle tempest plugin being able to be discovered by
Tempest, and support later integration test job.
3.What is the platform you tested it out?
It will work on all linux distribution including python venv, docker
container are available.
The procedure to make discovering processes are as follows:
Install the Tricircle after the patch merged (the Tricircle tempest
plugin and the sample tempest test case will be installed together for
they are in the same repository):
1. git clone https://github.com/openstack/tricircle.git
2. sudo pip install -e tricircle/
Install the Tempest in another folder in order to avoid the python
import error:
1. git clone https://github.com/openstack/tempest.git
2. sudo pip install -e tempest/
Then run testr in tempest folder to see if the test case of the Tricircle
has been discovered:
1. cd tempest/
2. testr list-tests | grep Tricircle
The Tricircle devstack plugin is also updated with the Tricircle package
installation in order to simplify the tempest discovering processes.
Change-Id: I977c23f5e55e3ee062190fa9d5e6472e5d5acb33
Signed-off-by: Chaoyi Huang <joehuang@huawei.com>
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>
Change the gate to OpenStack infrastrcuture and update the README.md
to reflect the work on the stateless design proposal and branch.
BP: https://blueprints.launchpad.net/tricircle/+spec/new-design
Change-Id: I51accdf33d8d9e50774c16d7649975ca91c2f5ec
Signed-off-by: Chaoyi Huang <joehuang@huawei.com>