1. What is the problem
Currently router operations are all done in the Tricircle plugin
in a synchronous way. Now we are going to support one top network
to spread into different availability zones, so not only the
Tricircle plugin but also the Nova_apigw need to handle router
operation. Also, having one top network spreading into several
availability zones means that we may need to operate routers in
several bottom pods at one time, so it's better to handle the
operations in an asynchronous way.
2. What is the solution to the problem
Reconstrut the code to move router operations to a new helper
module and add a new type of job to setup bottom routers, so both
the Tricircle plugin and the Nova_apigw can operate bottom routers
via xjob.
3. What the features need to be implemented to the Tricircle
to realize the solution
A new helper module is added while most of the codes is moved from
the Tricircle plugin. Also, a new type of job is added.
Change-Id: Ie5a89628a65c4d7cbcb2acd56bafe682580da2c6
1. What is the problem
The Tricircle Neutron plugin will call Neutron type manager's
function _add_network_segement, but Neutron has removed the
"mtu" parameter recently, this makes the check and gate test
in the Tricircle failed because the Tricircle still passes the
"mtu" parameter.
All check and gate test of python27 failed due to this change,
and any new patch is not able to be merged. The issue should
be fixed ASAP.
2. What's needed to be fixed:
Do not pass "mtu" to the function _add_network_segement.
3. What is the purpose of this patch set:
To get rid of the failure in check and gate test failure.
Change-Id: Id51cc9840e4bf2dd8e01b504502266e962c1e0c9
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
The Tricircle Neutron plugin will call Neutron type manager's
function _add_network_segement, the first parameter of this
function was "session" in the past, but Neutron has changed
the parameter to "context" recently, this makes the check
and gate test in the Tricircle failed because the Tricircle
still pass "session" as the first parameter.
All check and gate test of python27 failed due to this change,
and any new patch is not able to be merged. The issue should
be fixed ASAP.
2.What's need to be fixed:
Pass "context" but not "session" to the function
_add_network_segement.
3.What is the purpose of this patch set:
To get rid of the failure in check and gate test failure.
Change-Id: I78c64fe3cdd939cbdecf35fec0cff6cb44746cb0
Signed-off-by: Chaoyi Huang <joehuang@huawei.com>
1.What is the problem:
The nova team has decided to remove nova v2 API code completely.
And the patch have been merged.
Refer to https://review.openstack.org/#/c/311653/
2.What is the solution to the problem:
To fix the issue, we should bump to use v2.1 ASAP.
3.What is the purpose of this patch set:
The v2.1 API has been used as the default API since Liberty and legacy
v2 API has been marked as deprecated. Based on this, we bump to use
v2.1 ASAP for better development of the Tricircle.
Change-Id: I375a6509cf80613804f3fff19054d699dc5d8a1b
1. What is the problem
When running DevStack script of the Tricircle, during the setup
of Nova_apigw, script tries to add some configuration options to
the Neutron configuration file. However this file doesn't exist
at that time, thus script fails.
2. What is the solution to the problem
Stop modifying the Neutron configuration file during the setup
of Nova_apigw. Instead, we modify that file during the setup
of Neutron server.
3. What the features need to be implemented to the Tricircle
to realize the solution
No new features. Some lines of scripts are removed.
Change-Id: I94ada1e5a49f14942fa4c00690cffe2a87428e75
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 purpose of this patch set?
The Tricircle project doesn't provide integration test yet. As
the OpenStack API gateway, the Tricircle should pass the test for
all OpenStack tempest test cases.
When a feature parity is implemented in the Tricircle, proper
test cases should be selected and executed in the Jenkins integration
job.
To simplify the test cases selection, all tempest test cases of
Nova/Cinder/Neutron/Scenario are listed in the files
of this patch, and give example in tempest_volume.sh on how to run
selected test cases.
The hook scripts for the Jenkins job has been provided in:
https://review.openstack.org/#/c/329300/
This patch is to update the hook scripts.
2. What is the benefit of this patch set for the Tricircle project?
Reuse OpenStack Nova/Cinder/Neutron tempest test cases, and provide
integration gate test for new patches.
3.What is the platform you tested it out?
After the Jenkins job patch is merged, the test will be executed in
the OpenStack CI pipeline, and as one of the gate test for a new
patch. CI pipeline will be triggered by gerrit review process, and
the test will be executed in the devstack VM(booted by CI pipeline).
http://docs.openstack.org/infra/system-config/jenkins.html
And the Jenkin job patch is being review in OpenStack infra
project-config:
https://review.openstack.org/#/c/329740/
Change-Id: Ic5ec358889265e1d54071cd0d20e2aaa081736d1
Signed-off-by: Chaoyi Huang <joehuang@huawei.com>
The purpose of this patch set is to provide the end users with
the following functionalities:
1. Extend the size of the specified volume.
2. Set attachment metadata of the specified volume.
3. Update state of the specified volume.
4. Set image metadata of the specified volume.
5. Unset image metadata of the specified volume.
6. Show image metadata of the specified volume.
Change-Id: Ie9e4ca15a412c89a3c44f1b8526e6597eddf762c
1. What is the problem:
Neutron removes _allocate_specific_ip function
(https://review.openstack.org/#/c/303638/), but stub function
_allocate_specific_ip function still exsits in PluginTest, this will
lead to the Tricircle unit test failed.
2. What's need to be fixed:
In tricircle/tests/unit/network/test_plugin.py
remove the stub function _allocate_specific_ip.
3. What is the purpose of this patch set:
To make the Tricircle adapt to the change of Neutron so that the unit
test of the Tricircle could be exceuted successfully.
Change-Id: I8d0962dec7fd2a5421b93b1b26d416846e32e80c
The purpose of this patch set is to provide the end users with
the following functionalities:
1. Create volume metadata for a given volume.
2. Get the list of metadata for a given volume.
3. Update a given volume's metadata.
4. Delete an existing metadata of a given volume.
Change-Id: Id10eb6b9b68fcb2c496d1e8fa4fecec3c8d613d8
1. What is the problem
In the current controller implementation in nova_apigw and
cinder_apigw, pecan.abort is used to raise an exception when
error occurs. The problem of using pecan.abort is that the
response body doesn't have the same format with the error
response body in nova api and cinder api. Thus python client
may not correctly extract the error message, also, tempest
test may fail.
2. What is the solution to the problem
Replace pecan.abort with correct response body.
3. What the features need to be implemented to the Tricircle
to realize the solution
In this patch, we remove pecan.abort calls in controllers
of nova and cinder resources and directly return the error
response body with correct format. Controllers for the Tricircle
api still keep pecan.abort calls since we don't have special
requirement on the format of error response body.
Change-Id: I0e6fe9ddfce3f001fee0be2160d24c9c628d0a88
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
The purpose of this patch set is to provide the end users with
the following functionalities:
1. Create volume type resources, only admin is able to create volume type
2. Show details for a volume type by id
3. List volume types
4. Update a volume type, only admin is able to update volume type
5. Delete a volume type, only admin is able to delete volume type
Change-Id: I6e3188018eff6db155ec02dbd2af6aefc0363df9
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:
If availability zone (az in short) does not exit in the volume creation
request, 400 bad request was given in current handling, this handling is
incorrect and will block the following integration test cases:
ostestr --regex tempest.api.volume.test_volumes_list
ostestr --regex tempest.api.volume.test_volumes_get
Refer to https://review.openstack.org/#/c/329300/
2.What's need to be fixed:
To fix the issue, volume creation should allow no az parameter in
the request, and select one default bottom pod to continue the volume
creation.
3.What is the purpose of this patch set:
To make the integration test being the gate test of each patch set after
The Tricircle integration test Jenkins job is configured in
https://review.openstack.org/#/c/329740/
Change-Id: I8ee1cd5741605fbb105e2f24258459516aa7c5c0
1. What is the problem
In test_plugin module, we define a stub class FakePlugin to
bypass real database access for unit tests. In some previous
test cases, FakePlugin object is directly created and then
we test its function, but after some changes in Neutron, we
also need to register the class path of FakePlugin to an
configuration option called core_plugin, otherwise some of
test cases will fail with "core_plugin not configured" error.
2. What is the solution to the problem
Register core_plugin for each test cases.
3. What the features need to be implemented to the Tricircle
to realize the solution
Register core_plugin in setUp function then every test cases
can use this option.
Change-Id: Ibc2d81585ec8e67c3f56f864c4cbc5d2f0a0efa9
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
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
hook scripts for the Jenkins job to execute the test. The Tricircle
integration test Jenkins job will be configured in
https://github.com/openstack-infra/project-config/tree/master/jenkins/jobs
A Jenkins job patch will be submited to project-config once
this patch is merged. Without the hook scripts provided in this
patch, the Jenkins job configured in project-config is not able
to be executed successfully.
After the autotimc Jenkins job is established, all new patches
sumitted to the Tricircle should pass the integration test, i.e. the
test is also the gate test for a new patch.
For example, for cinder volume type patch, currently no integration
test is provided, we don't know the patch work or not.
As new features added to the Tricircle, integration test cases from
the Tempest for OpenStack Nova/Cinder/Neutron could be added to the
post_test_hook.sh, to test the features added to the Tricircle is
correct or not.
2.What is the benefit of this patch set for the Tricircle project?
Reuse OpenStack Nova/Cinder/Neutron tempest test cases, and provide
integration gate test for new patches.
3.What is the platform you tested it out?
After the Jenkins job patch is merged, the test will be executed in
the OpenStack CI pipeline, and as one of the gate test for a new
patch. CI pipeline will be triggered by gerrit review process, and
the test will be executed in the devstack VM(booted by CI pipeline).
http://docs.openstack.org/infra/system-config/jenkins.html
Change-Id: I5333681fdcaefb01498d9d8c6751d5d174bf57c2
Signed-off-by: Chaoyi Huang <joehuang@huawei.com>
1.What is the problem:
Neutron has just added one more parameter in _generate_ip function,
but there is no this parameter the stub function fake_generate_ip in
Tricircle plugin, this will lead to the Tricircle unit test failed.
2.What's need to be fixed:
In tricircle/tests/unit/network/test_plugin.py
update "def fake_generate_ip(context, subnets):" to
"def fake_generate_ip(context, subnets, prefer_next=False):"
3.What is the purpose of this patch set:
To make the Tricircle adapt to the change of Neutron so that the unit
test of the Tricircle could be exceuted successfully.
Change-Id: Ie715e3956f3ec7d3e3e4aedcd8b5e1c12c4df7ea
Signed-off-by: Chaoyi Huang <joehuang@huawei.com>
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>
According to the current design of cross pod L3 networking,
user needs to specify a pod when creating an external network
and the external network will be located in this pod. For VMs
located in other pods to access the external network, we need
a bridge network to connect these pods.
We assign the bridge network a CIDR allocated from a CIDR
pool. In the pod hosting the VM, say Pod_vm, a bridge external
network is created with the CIDR, so we can allocate a floating
ip from the CIDR and bind it to the VM port. In the pod hosting
the real external network(say "real" here to distinguish with
the bridge external network), say Pod_extnet, a bridge internal
network is created with the CIDR, so we can create a port with
the same ip as floating ip in Pod_vm, and bind it to the real
floating ip in Pod_extnet. With the bridge network, via two-step
DNAT, the VM can be accessed from the real external network.
For example, let's say we have an internal network with CIDR
10.0.1.0/24 and an external network with CIDR 162.3.124.0/24,
the CIDR of bridge network is 100.0.1.0/24, when binding a VM
ip 10.0.1.4 to a floating ip 162.3.124.5, the VM ip is first
bound to 100.0.1.4, which is allocated from 100.0.1.0/24, then
100.0.1.4 is bound to 162.3.124.5.
In the case that VM and external network are in the same pod,
bridge network is not needed.
So plugin needs to distinguish these two cases when handling
floating ip disassociation. If VM and external network are in
the same pod, plugin only disassociates the binding; if they
are in different pods, plugin also needs to release the ip
allocated from the bridge network.
Change-Id: Ibae353ec81aceda53016b6ea8aba1872d6d514be
In review I94f6f5f853078feeccaea0c50e5690101f95e318 tricircle is asking
to be added to projects.txt. Doing so will mean that when
global-requirements.txt is altered in a away that directly impacts
tricircle an automated (by proposal-bot) review similar to this one will
be generated.
This review manually performs this sync so that the first bot generated
change will be smaller and easier to review.
This introduces several significant changes (eventlet, ovo, Babel) so
please test carefully.
Change-Id: Ib2b7ed2671a5ad8d2a6262e07e0bbc5f921abf33
Permission of the following files is set to "-rwxrwxr-x".
It's not necessary for python scripts to be executable.
xjob/
__init__.py
xservice.py
xmanager.py
common/
baserpc.py
topics.py
serializer.py
rpc.py
xrpcapi.py
api
root.py
__init__.py
nova_apigw/
__init__.py
root.py
cinder_apigw/
root.py
__init__.py
Change-Id: Id397bf29574493bf1977ff40d0647d050fac2f5a
Signed-off-by: Chaoyi Huang <joehuang@huawei.com>
Closes-Bug: 1581271
Now oslo i18n _() returns a Message object which doesn't support
addition, so put all the texts in _() to avoid error.
Change-Id: I32ec2359200224e6e3e550bcca1e3fdf44b3d3c3
Use PortOpt and IpOpt as other OpenStack project does,
as PortOpt and IpOpt from oslo will perform checks to
ensure those configuration options are in correct form.
Change-Id: I914c930ce8427f6888ab120aeac6942a89f50824
Since neutron code bases was changed because of bug fix [1], network unit
test for the Tricircle has to be updated becuase of dependencies.
For More Detail:
neutron/db/ipam_backend_mixin.py
[1]https://review.openstack.org/#/c/288774/
Change-Id: I1142bdd75c1dd5d240d1d256d9687c2fe54612c8
This patch implements catching and logging of all abnormal exceptions. Relative tests are also written to check these exceptions.
Applied https://review.openstack.org/#/c/308940/ to solve network testing failed problem.
Change-Id: I18c39644924cd188d651037550151375f971d9d1
Closes-Bug: 1536929
zhiyuan_cai
Chaoyi Huang
OpenStack Proposal Bot
Kevin_Zheng
Jenkins
XiongQiu
Yipei Niu
Tony Breeds
Khayam Gondal