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
There is not this directory in debtcollector,so
we should drop it for improving searching efficiency.
Change-Id: Ia72a3cdcf3f5c02e491a535d212b44ee1eb3249c
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
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
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:
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?
In the original link, there are some problems:
* Sometimes, this link can't open.
* Some operation details is not clearly and easy to misleading.
2. What is the solution to the problem?
We have wrote a new document in the Wiki[1].
3. What the features need to be implemented to the Tricircle to
realize the solution?
None.
[1] https://wiki.openstack.org/wiki/Play_tricircle_with_virtualbox
Change-Id: I7253fe0cae82fe816a0fd4d175de27d12535399f
1. What is the problem?
The Tricircle Admin API documentation has been implemented, so the
relevant link to it in the document README.rst should be updated as
well.
2. What is the solution to the problem?
Remove the original null link at the bottom of the document README.rst and
change the part "Documentation" to "Tricircle Admin API documentation", then
provide the relative link behind it.
3. What the features need to be implemented to the Tricircle to realize the solution?
None.
Change-Id: I8dae02ddef4a3019abe91ec1ca283280b64c7c61
1. What is the problem
Pod and pod binding functions have been implemented, but the documentation
is not there.
2. What is the solution for the problem
Pod and pod binding have four main public functions respectively. For pod,
there are four public functions: 1) get pod list. 2) show a single pod in
detail. 3) create a pod. 4) delete a pod. Likewise, pod binding has four
similar public functions to pod. The file /tricircle/doc/source/api_v1.rst
includes the request and response explanation about each function.
3. What the features need to be implemented to the Tricircle to
realize the solution
None.
Change-Id: Ic530326bb00556b5b9e8d4e4699eaa35ebf01e61
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
Neutron is refactoring a lot of its code. For example, common entities
are being moved to neutron-lib. When code is refactored it is marked
with debtcollector, which issues a deprecation warning. In the next
release the old entity will be removed. Consuming projects (like
tricircle) must update to comply with the new entity before the old
one is removed.
Tricircle maintainers must monitor deprecation warnings and act on them
before the next release.
Many deprecations are triggered early (on imports, for example)
before the warnings are enabled by the WarningsFixture in the
base test class.
To make sure all DeprecationWarning messages are emitted we enable
them via the PYTHONWARNINGS environment variable.
Change-Id: Iade909b35a55cebb7dfe13a688f451ad91989b94
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 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>
