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
After running tempest test test_networks and test_ports, we find
some bugs on network and port query:
(1) Querying port with fields specified is not supported
(2) Querying port with ip address filter is not supported
(3) Querying network without id in the returned fields causes error
2. What is the solution to the problem
(1) Remove unnecessary fields before returning result
(2) If ip address filter is specified, join IPAllocation table to
filter ports
(3) If id is not in the specified field list, do not extend result
with segmentation information because network id is required to
retrieve segmentation information
3. What the features need to be implemented to the Tricircle
to realize the solution
Tempest test test_networks can be passed, to pass test_ports, we stil
need to support security group update and binding profile update.
Change-Id: Iec498fc72cd0dba74c908823f2d429537d52e0e2
1.What is the problem?
In nova-apigw, there are some servers with volume attachments
are not implemented:
* List volume attachments for an instance;
* Attach a volume to an instance;
* Show a detail of a volume attachment;
* Update a volume attachment;
* Detach a volume from an instance.
2.What is the solution to the problem?
This patch add three feature:
* We can get the volume identified by the attachment ID.
* We can get a list of all the attacned volumes.
* Detach a volume identified by the attachment ID from
the given server ID.
3.What the features need to be implemented to the Tricircle
to realize the solution?
The above three features.
Change-Id: I76ad72ca5d54fca7c2c463b5c41f2a4151f11eb8
Following OpenStack Style Guidelines[1]: http://docs.openstack.org/developer/hacking/#unit-tests-and-assertraises
[H203] Unit test assertions tend to give better messages for more
specific assertions. As a result, assertIsNone(...) is preferred
over assertEqual(None, ...) and assertIs(..,None)
Change-Id: I367cc785503dc4c9baa7f532610222f95d52eb50
1.what is the problem?
In tricircle, when a volume is in a stuck 'attaching' or 'detaching', Pod
can not detaching it by nova-apigw 'detach volume', so that this volume can
not reuse by ohther Pod. In addition, it may cause un-synchronization between
the Cinder database and the backend storage.
There is an user case in nova[1]. It may also occur on a tricircle Pod.
We don't need to worry about its security, because the Cinder api
'os-force-detach' is for safe cleanup. More user case and information
about 'force detach' in this document[2].
2.what is the solution to the problem?
We use Cinder api "os-force-detach" to detach it.
3. What the features need to be implemented to the Tricircle
to realize the solution?
Implement the force detach server action.
[1] https://blueprints.launchpad.net/nova/+spec/add-force-detach-to-nova
[2] https://github.com/openstack/cinder-specs/blob/master/specs/liberty/implement-force-detach-for-safe-cleanup.rst
Change-Id: If51ca17fc395dbb466b66514dec6c3fb66cd7519
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
1. What is the problem
To connect bottom routers in different pods, we need to create
bridge networks and subnets. These networks and subnets are not
deleted after bottom routers are deleted.
2. What is the solution to the problem
Clean these bridge networks and subnets during top router deletion.
3. What the features need to be implemented to the Tricircle
to realize the solution
Bridge networks and subnets now can be cleaned up.
Change-Id: I1f2feb7cba3dda14350b3e25a3c33563379eb580
1. What is the problem
The current Nova_APIGW does not support following server actions:
reboot: Reboots a server.
resize: Resizes a server.
confirmResize: Confirms a pending resize action for a server.
revertResize: Cancels and reverts a pending resize action for
a server.
os-resetState: Resets the state of 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: Ia3d0de1a42320cb1ee55b25210b227cb34a829a9
1. What is the problem
Before creating bottom subnet, we need to create some ports to
allocate ip address for bottom dhcp port and bottom gateway port.
These pre-created ports are not deleted after bottom resources
are deleted.
2. What is the solution to the problem
Clean these pre-created ports during top subnet deletion.
3. What the features need to be implemented to the Tricircle
to realize the solution
Pre-created ports now can be cleaned up.
Change-Id: I73c0ef87e4104f1db9926a5972c5f36be94d724a
1. What is the problem?
After updated to version 1.2, the WSGI framework we use, pecan has a
behaviour that if the handle function return None, the setting of
resonse status code will not take effect. In the deletion handle
functions of pod and pod-binding controllers, we set the response
status code but return None, thus the status code is not changed and
our tests fail.
2. What is the solution to the problem?
Return an empty dict in the deletion handle functions.
3. What the features need to be implemented to the Tricircle to realize
the solution?
No new features.
Change-Id: I4bc44d2bc774fbe0cd9f820361d35077c83f3973
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
User cannot correctly delete floating ip via the Tricirce plugin.
2. What is the solution to the problem
Overwrite delete_floatingip method in the Tricircle plugin. We
first update the floating ip to disassociate it with fixed ip,
then invoke delete_floatingip method in the base class to delete
the database record.
3. What the features need to be implemented to the Tricircle
to realize the solution
Deletion of floating ip is now supported.
Change-Id: Ia8bf6e7499321c1be085533e8695eea6ac8ef26d
1.What is the problem:
Currently Admin-API is to manage pod and pod-binding, the Admin-API
access is hard coded, and only admin role is allowed. OpenStack
usually use policy.json based authorization to control the
API-request. Policy feature is missing in the Tricircle.
2.What's need to be fixed:
Remove hard coded Admin-API request authorization, use policy instead.
For Nova API-GW and Cinder API-GW, the API access control should be
done at bottom OpenStack as far as possible if the API request will
be forwarded to bottom OpenStack directly for further processing;
only these APIs which only interact with database for example flavor
and volume type, because these APIs processing will be terminated at
the Tricircle layer, so policy control should be done in Nova API-GW
or Cinder API-GW. No work needs to do in Tricircle Neutron Plugin for
Neutron API server is there, Neutron API server will be responsible
for policy control.
3.What is the purpose of this patch set:
In this patch, default policy option and rule, and policy control
in Admin-API were added. Using the default option and value to
generate the policy.json will be implemented in next patch. No
policy.json is mandatory required after this patch is merged,
if no policy.json is configured or provided, the policy control
will use the default rule automatically.
Change-Id: Ifb6137b20f56e9f9a70d339fd357ee480fa3ce2e
Signed-off-by: joehuang <joehuang@huawei.com>
1. What is the problem
Neutron now reads project_id field from Context object for privilege
validation, but in our unit tests, FakeNeutronContext object which
simulates Context object doesn't have project_id, thus unit tests
fail to pass.
Also, Neutron now calls expunge method in Session object which the
simulation object FakeSession doesn't have that method.
2. What is the solution to the problem
Add project_id field to FakeNeutronContext object, and make sure
project_id fields set in FakeNeutronContext object and resource
object are the same.
Use __getattr__ to return a dummy method if the method hasn't been
defined in FakeSession object.
3. What the features need to be implemented to the Tricircle
to realize the solution
No new feature introduced.
Change-Id: I58fb446dc7837065a60aafd5c6c6262840b60e21
1. What is the problem
The current Nova_APIGW does not support microversion function, the service
controller uses a fixed API version number to initialize novaclient
2. What is the solution to the problem
When the service controller receives an API request, it will get the
microversion number from request headers , and use this to initialize
novaclient.
For how to get the microversion number, please refer to:
https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
The microversion supported range is 2.1 to latest version
3. What the features need to be implemented to the Tricircle
to realize the solution
Nova_APIGW microversion support added
Change-Id: Idf44c91100e5cb8ad0355164c9be991aa54a652b
1. What is the problem
Shared vlan type driver has been merged, so we can run two VMs in
the same network but across two pods. However if we attach a network
to the router, the tricircle plugin still check if the network is
bound to one AZ, so one network cannot cross different pods if we
are going to attach it to a router.
2. What is the solution to the problem
The reason we require network to be bound to AZ is that when the
network is attaching the one router, we know where to create the
bottom network resources. To support l3 networking in shared vlan
network, we need to remove this restriction.
In the previous patches[1, 2], we have already move bottom router
setup to an asynchronouse job, so we just remove the AZ restriction
and make the tricircle plugin and the nova_apigw to use the job.
Floating ip association and disassociation are also moved to bottom
router setup job.
3. What the features need to be implemented to the Tricircle
to realize the solution
Now network can be attached to a router without specifying AZ, so
l3 networking can work with across-pod network.
[1] https://review.openstack.org/#/c/343568/
[2] https://review.openstack.org/#/c/345863/
Change-Id: I9aaf908a5de55575d63533f1574a0a6edb3c66b8
1. What is the problem
To simulate Neutron database operations in unit tests, FakeQuery and
FakeSession are defined to replace the original Query and Session
objects. After service subnets feature is merged into Neutron[1], during
ip allocation, Neutron calls Query.add_entity to query subnet by service
type. However, FakeQuery object doesn't have add_entity method, thus
unit tests fail to pass.
2. What is the solution to the problem
Mock _allocate_ips_for_port to bypass the service subnet query, which
is not necessary in the unit tests.
3. What the features need to be implemented to the Tricircle
to realize the solution
No new feature introduced.
[1] https://review.openstack.org/#/c/350613/
Change-Id: Ieec7f5ab7b63cba0b1c9569e87dd894dd34b07c2
1. What is the problem
After recent updates now Neutron uses pluggable IPAM driver backend by default,
while in the unit tests for network functionality in the Tricircle, unpluggable
IPAM driver backend is assumed to be used. So this default backend change causes
most of the unit tests fail.
2. What is the solution to the problem
In the setup of unit tests, set "ipam_driver" option as empty string to use
unpluggable IPAM driver backend.
3. What the features need to be implemented to the Tricircle
to realize the solution
No new feature introduced.
Change-Id: Ifa85d4e209ac0fa04c21db316eee6ebc41981dab
1.What is the problem:
If availability zone (az in short) does not exit in the server creation
request or extenal network, 400 bad request was given in current handling,
this handling is inconsistent with Nova and Neutron.In Nova and Neutron,
az is one optional parameter, i.e, even the az is not speficied in the
request, a scheduled az should be used for the creation, but not
return 400 bad request.
2.What's need to be fixed:
To fix the issue, server creation should allow no az parameter in
the request, and select one default bottom pod to continue the server
creation.
3.What is the purpose of this patch set:
To make the az handling behavior is consistent with that in Nova and
Neutron.
Change-Id: I9281914bad482573c6540bf2a14e51e7ca4d744c
Signed-off-by: joehuang <joehuang@huawei.com>
1.What is the problem:
If 'networks' is not carried in the request to Nova API-GW,
then in current implementation, server_body['networks'] will
not be initialized before it is used in the "nics = [ {'port-id':
_port['port']} for _port in server_body['networks']]" clause,
then exception will happen, and return error to the API caller.
In fact, it should works, no exception should happen.
2.What's need to be fixed:
Move the server_body['networks'] initialization outside
the "if 'networks' in kw['server']" clause will ensure
server_body['networks'] being initialized before it is used
later, and eliminate the exception happened in "nics = ...
for _port in server_body['networks']]" clause.
3.What is the purpose of this patch set:
Eliminate the unusual exception happened in server creation
Change-Id: I50a6ac8e6bba78233e063bcfc24c0a1d4663e9f6
Signed-off-by: joehuang <joehuang@huawei.com>
1.What is the problem:
Python requests lib is used to forward the http request from the Cinder
API-GW to bottom Cinder. Now the latest version of the requests lib
add stricter header validity check: only bytes or string is allowed for
header item's value, other value will lead to exception, even for "None".
But Cinder client will pass some header items with "None" value in the
api request to Cinder API-GW, thus lead to the exception in Cinder API-GW
when forwarding the request to the bottom Cinder via requests lib, which
lead to the integration failed, and block any patch to be merged.
2.What's need to be fixed:
Remove(clean) the invalid header items in the request to the bottom
Cinder, in which the python requests lib is used. So that integration
test can pass, and make patch being able to be merged.
3.What is the purpose of this patch set:
Fix the integration test failure issue casued by strict validity check
in http header processing.
Change-Id: Iff6d2dd77571180ef9a0cad2171c479be63bd880
Signed-off-by: joehuang <joehuang@huawei.com>
1. What is the problem
Our current mechanism to handle dhcp port creation is that we first
create the top dhcp port, then use the allocated ip to create the
bottom dhcp port. If we get an "IpAddressInUse" error, meaning that
bottom dhcp agent has already created the dhcp port with the same
ip, we just reuse the port; otherwise, we successfully create the
bottom dhcp port, we remove other dhcp ports with different ips, so
dhcp agent can be notified and use the bottom dhcp port we create.
However, we find that this mechanism doesn't work in the following
situation. Dhcp agent may create the bottom dhcp port after we do
the check about whether other dhcp ports exist, so we don't remove
the dhcp port created by dhcp agent, thus we end up with two bottom
dhcp ports, one is created by dhcp agent, one is created by us.
2. What is the solution to the problem
Create bottom subnet with dhcp disabled, so dhcp agent will not be
scheduled, then create bottom dhcp port and update bottom subnet
to enable dhcp. Finding that there is already a reserved dhcp port,
dhcp agent will not create another dhcp port and directly use the
existing one.
3. What the features need to be implemented to the Tricircle
to realize the solution
No new feature introuduced.
Change-Id: I8bb8622b34b709edef230d1f1c985e3fabd5adb0
1.What is the problem
core_opts has been moved from neutron/common/config.py to
neutron/conf/common.py, the migration leads the py27 test failured
in tricircle/tests/base.py.
2.What's need to be fixed:
import common.py from neutron/conf/common.py instead from
from neutron/common/config.py
3.What is the purpose of this patch set:
fix the py27 check and gate test error introduced by Neutron
config file refactorying.
Change-Id: Icab2d6a2e25cc3387e5ee9951cc0b53491e012ee
Signed-off-by: joehuang <joehuang@huawei.com>
1. What is the problem
Currently dhcp port handle is only done in the Nova_apigw. Please
refer to our design documnet[1] to see why dhcp port needs special
process, which is discussed in section 7.4.10. Since we are going
to support one top network to spread into different AZs(availability
zones), routers will be created in different AZs. For shared VLAN
type network, bottom networks in different AZs are actually in the
same broadcast domain, so router gateway IPs should be different
in different AZs, otherwise we have two interfaces with the same
IP in the same broadcase domain. Thus, we need to allocate one IP
for each bottom router and the Tricircle plugin needs to handle
dhcp port creation.
2. What is the solution to the problem
Reconstrut the code to move dhcp port handle from the Nova_apigw
to the helper module, so both the Nova_apigw and the Tricircle
plugin can use.
3. What the features need to be implemented to the Tricircle
to realize the solution
No new feature introuduced.
[1] https://docs.google.com/document/d/18kZZ1snMOCD9IQvUKI5NVDzSASpw-QKj7l2zNqMEd3g
Change-Id: I2525a7a18761ef4aa8c6e743cb46ed238a313731
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
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 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:
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
zhiyuan_cai