1. What is the problem
Create instance can't find image and the document need to update
2. What is the solution to the problem
Change the plugin.sh to fix the error of image not found
update the document for work with nova cell v2
3. What the features need to be implemented to the Tricircle
None
Signed-off-by: chenyaguang <chenyaguang@szzt.com.cn>
Co-Authored-By：tangzhuo <ztang@hnu.edu.cn>
Change-Id: I3deec4a2d8315d92d383157f20f101dfef11ddcd
1. What is the problem?
the smoke test can not pass, because the
new version of openstack-sdk change.
2. What is the solution to the problem?
use the new method for the new version openstack-sdk.
3. What the features to be implemented in the Tricircle to realize the solution?
No new features.
Change-Id: I642086dac5d1320c7a04adf756b9bfe74a08a68c
Signed-off-by: song baisen <songbaisen@szzt.com.cn>
Co-Authored-By: zhiyuan_cai <luckyvega.g@gmail.com>
1. What is the problem?
When receiving a request, we don't know whether the request
comes from 'Central Neutron' or 'Local Neutron'.
2. What is the solution to the problem?
In order to determine the source of requests, we add a
filter to get the source message in the header of requests.
Next step we tag the source message into the context. When
deploy the WSGI app, we checkout the User-Agent in the
request's headers and tag the requests.
3. What the features need to be implemented to the Tricircle
to realize the solution?
No
Change-Id: I990fa46e887cc0822b8e6d74d199d92e39df0bd6
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>
1. What is the problem?
Currently no doc is there for installing and configuring LBaaS.
2. What is the solution to the problem?
Add installation and configuration guide for LBaaS.
3. What features need to be implemented to the Tricircle to realize
the solution?
None
Change-Id: I73b48b88c341ac154e9714dfb855e283981d97e7
1. What is the problem
Smoke test tries to modify tempest config file but gets a
"permission deny" error.
2. What is the solution for the problem
Since we don't need tempest, we just remove the config.
Also temporarily skip trunk smoke test because of neutron
bug 1722967
3. What features need to be implemented to the Tricircle to
realize the solution
N/A
Change-Id: I8489a797fbd3b584dc2b8556df5e50dd0b6133bd
1. What is the problem
After the Pike release, systemd becomes the only runner for
services, also more services adopt the mod_wsgi way to start
their API server. As a result, our plugin.sh script and
document for cellv2 integration don't work now.
2. What is the solution for the problem
Update plugin.sh and document to adapt the changes.
3. What features need to be implemented to the Tricircle to
realize the solution
N/A
Change-Id: I34843e1f765e8b0e64f68f0d89fe9e63106b60e4
1. What is the problem
Tricircle cli has been implemented and can be used instead of curl,
it's more user friendly and convenient.
2. What is the solution for the problem
Update curl command with tricircle cli.
3. What the features need to be implemented to the
tricircle to realize the solution
None.
Change-Id: Ib272c9cb53db06eb7185661953af1b46f54790d0
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
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
1. What is the problem
The segment ID of local type network is allocated in the local Neutron
server, so it's possible that segment IDs of bridge network and local
network conflict, which results to failure when creating bridge network.
2. What is the solution for the problem
Since network AZ is implemented, we can deprecate the "local" network
type and only create a local network by specifying AZ as region name.
Before such deprecation, we change local type as the last network type
candidate to avoid users create a local type network by mistake.
3. What features need to be implemented to the Tricircle to
realize the solution
N/A
Change-Id: I55a1b6a93bd43e28c05530161e23de26a8bb8f60
Partial-Bug: #1692415
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
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
1. What is the problem?
Now Keystone uses uwsgi with proxy[1], and this is the default mode
in DevStack. In this case, the original URL with 5000/35357 port can
no longer be accessed, this change will lead to Tricircle gate/check
test always failure if no adaption is made in Tricircle configuration.
After patch[2] merged, update mac address will also trigger ip updating
process. This is mainly for IPv6 address but the code logic doesn't
distinguish ip version. Some methods used by ip updating process are not
correctly simulated in FakeQuery so test_update_port test failed
2. What is the solution to the problem?
Change Keystone public URL Tricircle uses from
http://host:5000/v3 to http://host/identity and
change Keystone admin URL Tricircle uses from
http://host:35357/v3 to http://host/identity
This patch also fixes a mistake which was hidden before this Keystone
change. While generating Tricircle apache configuration file in our
DevStack script, TRICIRCLE_BIN in the template is not replaced by
the real value. So the directory access right is not correctly granted.
Before this Keystone change, Keystone apache configuration file will
grant right on the same directory, so we didn't notice this problem.
Since we don't support ip updating currently, one simple fix is to mock
_update_ips_for_port method.
3. What features need to be implemented to the Tricircle
to realize the solution?
No new features.
[1] https://github.com/openstack-dev/devstack/commit/
6ed53156b6198e69d59d1cf3a3497e96f5b7a870
[2] https://github.com/openstack/neutron/commit/
46d1a890e700dfa6e921387569f87f793ca4e8e9
Change-Id: I2b43c630eedff0f808c729da0ce9b819f02495dd
1. What is the problem?
Multi-region test has been added to our check/gate jobs, but the
test just installs Tricircle via DevStack and doesn't provision
any resources like network/subnet/router/server, so Tricircle
functionality is not tested.
2. What is the solution to the problem?
Add a script in the test to create a basic network topology via
central Neutron and check if local resources are correctly created.
In the topology, two tenant networks are connected by a router, an
external network is attached to the router. We boot one server in
each tenant network and associate a floating IP to one of the server.
This patch also fixes a problem brought by
(1) Eliminate lookup of "resource extend" funcs by name
92372b982f
(2) Defer service_plugins configuration
a8204752e3
We can put these changes in a standalone patch, but let's first put them
here to test by this smoke test.
3. What features need to be implemented to the Tricircle
to realize the solution?
Tricircle functionality can be tested.
Change-Id: Ib364a96fe4c3b9b635e5fac979c7c1cba2aaefc9
1. What is the problem?
As discussed in the spec[1], we lack support of one deployment
scenario that each OpenStack cloud provides external network
for north-south traffic and at the same time east-west networking
of tenant networks between OpenStack clouds are also enabled.
2. What is the solution to the problem?
Implement a new layer-3 networking model discussed in the spec[1].
3. What features need to be implemented to the Tricircle
to realize the solution?
Xmanager is modified to properly configure router interface, router
extra routes and subnet host routes for the new model.
[1] https://github.com/openstack/tricircle/blob/master/specs/pike/
l3-networking-multi-NS-with-EW-enabled.rst
Change-Id: I34ad7dbf01be68f4544b2170b2cfe90097c4edf5
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?
This is not a bug fix but to attend naming inconstistency
at this early stage of the project.
2. What is the solution for the problem?
To correct and maintain a consistent naming sequence for project.
3. What features need to be implemented for Tricircle?
None
Change-Id: I84d6e2aa76f0e61f39f20cacf19fe6333d82aa1f
Closes-Bug: #1571136
1. What is the problem?
The spec and implementaion of vxlan network support have been
submitted, but we lack updating related documents and adding
a release note.
2. What is the solution to the problem?
Update related documents and add a release note.
3. What the features need to be implemented to the Tricircle
to realize the solution?
N/A
Change-Id: I392022226b06e75f7813befc78927cb5779e0a45
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
(1) Currently we only add bridge mapping for br-extern in RegionTwo by
default in plugin.sh, so if we only have one node for the tempest
test, we can not test the cases that network is created in physical
network of "extern".
(2) Keystone url is not configured explicitly in tricircle local
Neutron plugin configuration so local Neutron plugin may fail to connect
to central Neutron.
(3) In multi-pod installation, Nova services in node2 fail to talk to
placement API due to placement API configuration problem, which leads
to instance booting error.
2. What is the solution to the problem
(1) Add bridge mapping for br-extern both in RegionOne and RegionTwo
by default.
(2) Configure two options client.identity_url and client.auth_url in
plugin.sh to make sure local Neutron server can correctly connect to
central Neutron server.
(3) Update multi-pod installation guide to add a workaround for the
placement API problem.
3. What the features need to be implemented to the Tricircle
No new features.
Change-Id: I0925ee976a3bc7ce16b5ac19865c08dedb2de423
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
1. What is the problem
when creating an external network with provider physical
network specified as 'extern', central Neutron will complain
that the specified physical network is not found.
2. What is the solution to the problem
Add 'extern' as physical network to Q_ML2_PLUGIN_VLAN_TYPE_OPTIONS
when init local neutron variables.
3. What the features need to be implemented to the Tricircle
No new features
Change-Id: I3948bcc8b4498ad2f3a14679fbed9ce8ae3ad113
Closes-Bug: #1657634
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?
Using tempest plugin in conjuction with
NEUTRON_CREATE_INITIAL_NETWORKS to set False was causing failures
during the execution of the stack.sh script. This issue was solved
in I62e74d350d6533fa842d64c15b01b1a3d42c71c2 but it hasn't reflected
on the devstack samples.
2. What is the solution to the problem?
Let the users to enable or disable the tempest usage on their devstack
environments.
3. What the features need to be implemented to the Tricircle to
realize the solution?
No new features
Change-Id: Iad563a660ea58faa57984ee7829ee45e5811c900
1. What is the problem?
The local.conf.sample provided as an example of a configuration file
for Devstack contains deprecated, default and legacy values. Besides,
the devstack plugin script has some errors, e. g. call to invalid
functions, mandatory values, legacy services(q-svc), etc.
2. What is the solution to the problem?
Reducing the number of values required to for using tricircle can
help for the adoption and new developers as well as easier deployment
in Devstack.
3. What the features need to be implemented to the Tricircle to
realize the solution?
No new features
Change-Id: I37c5d5507a8461fd521455c4e2f172ac97eaa5c4
1. What is the problem
Based on the bug report https://bugs.launchpad.net/tricircle/+bug/1652708,
currently the version migrated to is fixed to 2 in cmd/manage.py.
2. What is the solution to the problem
We should use the version specified in the CLI, if no target version is
specified, then migrate the db to the latest version.
3. What the features need to be implemented to the Tricircle
No new features
Change-Id: I00703578ecd2017836be9ac6e93a4bfd784e650e
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>
1. What is the problem?
The current implementation of bridge networks has some problems
when supporting DVR and shared VxLAN network. One blueprint has
been registered[1] and the specification document has also been
submitted[2].
2. What is the solution to the problem?
The logic of bridge network operations will be changed, here lists
some major changes:
(1) Only one bridge network will be created for one project
(2) Bridge network is attached to local router as external network
(3) One local router dedicated for north-south networking will be
created in the pod hosting real external network. Bridge network
is attached to this special router as internal network
(4) If the instance port is not located in the pod hosting real
external network, after floating ip association, one "copy" port
will be created in the pod hosting real external network. Without
this port, local Neutron server will complain that it cannot find
the internal port going to be associated.
3.What the features need to be implemented to the Tricircle
to realize the solution?
Bring part of the DVR support to cross-pod layer-3 networking
[1] https://blueprints.launchpad.net/tricircle/+spec/combine-bridge-net
[2] https://review.openstack.org/#/c/396564/
Change-Id: I53d1736ab30d3bc508279532609285975988b5f4
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?
Most of the OpenStack Services register themselves using
get_or_create_service function using name and type lower-case
arguments. This is required for python clients to discover the
endpoints of the service.
2. What is the solution to the problem?
Change to lower-case the type of the service to meet this
requirement.
3. What the features need to be implemented to the Tricircle
to realize the solution?
None
Change-Id: Ie96b231ee2176071a9ad8d2323a19c7c2af1fa7e
1. What is the problem?
Tricircle uses python script commands to setup and start the screens
in devstack. Given the last addition of tricircle commands in
I6a27d990803e928151ca424f47564b6626c8e99b this solution could be
improved.
2. What is the solution to the problem?
Replace the python script commads for tricircle commands and fix
the tricircle-db-manage binary.
3. What the features need to be implemented to the Tricircle to
realize the solution?
None
Change-Id: I7c2e28d6be58b4d1e72ca792d52ccc73d3f7b756
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: I988a974e8887c09c730bc0172aacee0fb85b2c3b
1. What is the problem?
When installing tricircle using devstatck, the tricircle endpoint can not
be successfully registered
2. What is the solution to the problem?
Remove KEYSTONE_CATALOG_BACKEND equal to 'sql' judgement
3. What the features need to be implemented to the Tricircle to realize
the solution?
No new features
Change-Id: I214c3e6942a53707616a7d46d39a3a5b2936366f
1. What is the problem
Necessary changes for local plugin and central plugin to boot
a virtual machine have been submitted in this patch[1]. As the
next step, we need to add l3 functionality to the local and
central plugin.
2. What is the solution to the problem
Several changes in local plugin.
(1) Before creating local subnet, local plugin sends request to
central plugin to create a "reserved gateway port", and use the
ip address of this port as the gateway ip of the local subnet.
(2) When local plugin receives network or subnet creation request,
if the request contains "name" parameter and the name is a UUID,
local plugin uses the name as the id of the local network or
subnet.
3. What the features need to be implemented to the Tricircle
to realize the solution
With this patch, users can connect virtual machines booted
directly via the local Nova server in different networks with
a router.
[1] https://review.openstack.org/375281
Change-Id: I12094f30804c0bad2f74e0ff510ac26bd217cfd4
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
1. What is the problem
The current Nova_APIGW does not support following server actions:
os-start: Start server
os-stop: Stop server
lock: Locks a server
unlock: Unlocks a locked server
pause: Pause server
unpause: Unpause server
resume: Resumes a suspended server and changes its status to ACTIVE
suspend: Suspend a server
shelve: Shelves a server
unshelve: Shelves a server
shelveOffload: Shelf-offloads, or removes, a shelved server
migrate: Migrates a server to a host. The scheduler chooses the host.
forceDelete: Force-deletes a server before deferred cleanup
trigger_crash_dump: Trigger a crash dump in a server
2. What is the solution to the problem
Implement the above server action
3. What the features need to be implemented to the Tricircle
to realize the solution
Add the above server action
Change-Id: I6a65938f1797380a896efe8f6aaed6a1903c82ca
1. What is the problem
After enabled neutron in tempest, DevStack by default creates
initial network, including external network. However, currently
creating external network requires specifying AZ, which is not
supported yet in neutron client, so DevStack fails to create
external network, and thus DevStack fails to run.
2. What is the solution to the problem
Disable initial network creation in DevStack configuration
3. What the features need to be implemented to the Tricircle
to realize the solution
No new features
Change-Id: I620a77157e7a73e4e4c8b18820eb4a70ccf0d497
1. What is the problem
Communities require above services enable in devstack plugin.sh
keep consistency with other project.
Andreas Jaeger's opinion:
Enabling the plugin should be enough, if those are needed,
they should be part of the plugin.Please refer:
https://review.openstack.org/#/c/367220/
2. What is the solution to the problem
Enable above services in devstack plugin.sh
3. What the features need to be implemented to the Tricircle
to realize the solution
Enable the above service in devstack plugin.sh
Change-Id: I96a60ff59776d429917f365aa50715cf6c38d39b
1.What is the problem
Multiline regex does not work in ostestr which is executed
in the integration job. This makes the test_volume_get test
cases not being executed currently in the check and gate test.
After regex issue is fixed, then
test_volume_create_get_update_delete_from_image
test case failed due to no image_ref is configured in the
tempest.conf, so the tempest configuration is moved to
the post_test_hook.sh, and correct the image_ref configuration.
2.What's need to be fixed:
If we want to add more and more tempest test cases to the
integration job, we have to add the filter of them to the
regex in the same line, so a string variable is used to
concat these filters for the tempest test cases.
And need to add image_ref configuration in tempest.conf.
And fix the bug for Pecan can not handle the last '/' in the
request url, which will lead to the tempest test case
test_volume_create_get_update_delete_from_image failure
in the check and gate test.
3.What is the purpose of this patch set:
To make the integration job work well, we have to fix the
regex part of the ostestr in the integration job, and fix
the configuration issue in tempest.conf, and Pecan bug.
Change-Id: I63e8e5e6372719f68051a486951b32d479607eff
Signed-off-by: Chaoyi Huang <joehuang@huawei.com>
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
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 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>
Bug in DevStack[1] which affects multi-region deployment has been
fixed. Update readme to adapt this DevStack change.
[1] https://bugs.launchpad.net/devstack/+bug/1540802
Change-Id: I19876c359910741e5fe5babdd209b06f126b0d4f
Implement l3 north-south networking functionality. In our current
design, external network is hosted in one of the bottom pod, VMs
hosted in other bottom pods are connected to this external network
via a bridge network, using the same physical network as the east-
west networking, but different vlan.
Change-Id: I953322737aa97b2d1ebd9a15dc479d7aba753678
chenyaguang
songbaisen
lyman-xu
zhangxiaohan
Yipei Niu
zhiyuan_cai
Dongfeng Huang
Victor Morales
nanaboat
joehuang
xiulin yin
Kevin_Zheng
zhangyanxian
shipengfei92
Bean Zhang