1. What is the problem?
Tricircle plugin is not installed in node_2 according to this guide.
Devstack on node_2 will fail because of this.
2. What is the solution to the problem?
Install tricircle in node_2 before running devstack.
3. What the features need to be implemented to the Tricircle to realize the solution?
No new features.
Change-Id: I51902bb7b2abdfba282409fbc6d9f2c435b4dc9c
Signed-off-by: Alex Yang <yangyang1@zte.com.cn>
1. What is the problem?
There is no release notes in master branch, then the user of
Tricircle don't know what features supported, what features not
supported.
2. What is the solution to the problem?
Add release notes to outline what features supported for the Tricircle
project.
3. What the features need to be implemented to the Tricircle to realize the solution?
No new features.
Change-Id: I4270730bd5def464b9814f7b457a0316a6dd1a0e
1. What is the problem?
The current installation guide is based on the Tricircle with
API-GW and networking automation functionality. After the Tricircle
splitting, only networking automation will be remained in the
Tricircle repository, so the current installation guide will not
work anymore.
2. What is the solution to the problem?
Update the installation guide to reflect the Tricricle splitting.
This patch will focus on multi-node installation with DevStack.
Single node installation with DevStack has been updated in this
patch[1].
3. What the features need to be implemented to the Tricircle to realize
the solution?
No new features.
[1] https://review.openstack.org/#/c/384872
Change-Id: I8ee326024fd152133829caced69a68348172f065
1. What is the problem
Necessary changes for local plugin and central plugin to boot
a instance have been submitted in this patch[1], but security
group has not been supported yet.
2. What is the solution to the problem
(1) Modify local plugin that when security group query request
is sent to local Neutron server, local plugin retrieves
information from central Neutron server and creates necessary
local security group.
(2) Add a new job to xjob to sync security group rules across
OpenStack instances.
3. What the features need to be implemented to the Tricircle
to realize the solution
With this patch, users can boot a instance directly via
the local Nova server with security group supported.
[1] https://review.openstack.org/375281
Change-Id: Ibc9898ac577bee19a017746356a8f826e0a8b16f
1. What is the problem?
The current installation guide is based on the Tricircle with
API-GW and networking automation functionalities. After the
Tricircle splitting, only networking automation will be remained
the Tricircle repository, so the current installation guide
will not work anymore.
2. What is the solution to the problem?
Update the installation guide to reflect the Tricricle splitting.
This patch will focus on single node installation with DevStack.
Multi-node installation with DevStack will be update in another
patch: https://review.openstack.org/#/c/385306/.
3. What the features need to be implemented to the Tricircle to realize
the solution?
No new features.
Change-Id: I0d5a3a9673a34ca8eb96a07f2eafbb1b931ef55f
Signed-off-by: joehuang <joehuang@huawei.com>
1. What is the problem?
Nova API-GW and Cinder API-GW code are still in the repository of
the Tricircle project.
2. What is the solution to the problem?
According to the blueprint for the Tricircle splitting:
https://blueprints.launchpad.net/tricircle/+spec/make-tricircle-dedicated-for-networking-automation-across-neutron
Nova API-GW and Cinder API-GW related code should be removed from
the repository of the Tricircle project.
3. What the features need to be implemented to the Tricircle to realize
the solution?
No new features.
Change-Id: I152bab9c0a7a114f0361a69a3ab2d7037731434f
1. What is the problem
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
Releasenote translation publishing is being prepared. 'locale_dirs'
needs to be defined in conf.py to generate translated version of the
release notes.
Note that this repository might not get translated release notes - or
no translations at all - but we add the entry here nevertheless to
prepare for it.
Change-Id: Iafe553ce5b54854a3d5d19baf498a289fc4753e0
1. What is the problem?
After splitting, the Tricircle will be dedicated for
networking automation across Neutron, so the README.rst
and setup.cfg need to be updated
2. What is the solution to the problem?
Update README.rst and setup.cfg file in the github.
3. What the features need to be implemented to the Tricircle to realize
the solution?
No new features.
Change-Id: I92c525feb6ff059ae59e82b3f54fedd5f14789a5
Signed-off-by: joehuang <joehuang@huawei.com>
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
1. What is the problem?
In the original spec, there are some fuzzy descriptions:
* Before we run the commands to test some functions in the Tricircle,
we need to import the environment variables. So it is necessary to
describe this file "admin-openrc.sh" more clearly before test.
* When creating pod instances for Tricircle and bottom OpenStack,
this document lack the instructions for the parameter "token".
* Some volume actions tests lacked in this document.
2. What is the solution to the problem?
We add some descriptions about environment variables and parameter
"token". We also add some volume actions tests in this document.
3. What the features need to be implemented to the Tricircle to
realize the solution?
None
Change-Id: Id8439415548a4366b0d4e0cfbf3886e5f1ee5bb9
1. What is the problem
Part of the networking automation functionality is implemented
in the Nova-APIGW, which bring coupling between Neutron and Nova
servers. Users must deploy Nova-APIGW if they want to use the
networking automation function, which is not flexible.
2. What is the solution to the problem
Move the process of networking automation from the Nova-APIGW
to local Neutron plugin. This specification covers the detailed
introduction and discussion of this plugin.
3. What the features need to be implemented to the Tricircle
to realize the solution
The local Neutron plugin discussed in this specification needs
to be implemented.
Change-Id: I6450ab0d2103eb8fd6fa8869ae80376a37ae371a
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
Tricircle already uses PBR:-
setuptools.setup(
setup_requires=['pbr>=1.8'],
pbr=True)
This patch removes `MANIFEST.in` file as pbr generates a
sensible manifest from git files and some standard files
and it removes the need for an explicit `MANIFEST.in` file.
Change-Id: I722651c1c3082ec59c0408a12db7b14c404d7ce7
Closes-Bug: #1608980
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
