1. What is the problem?
The networking guide "North South Networking via Single
External Network" has not been described exactly to reflect
the practice deployment.
2. What is the solution to the problem?
Update topology and description for where to deploy the
single external network, what happens if external
network and local network are located in same region.
3. What features need to be implemented to the Tricircle
to realize the solution?
No new feature.
Change-Id: I16fe30af0b0f62404c48c20415321e7248b7d412
Signed-off-by: joehuang <joehuang@huawei.com>
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.
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].
With the previous parts[2, 3, 4], VxLAN network already works for
tenant network, but bridge network still lacks VxLAN network support.
2. What is the solution to the problem?
We need to build VxLAN tunnels for bridge ports, so bridge port
creation should also trigger shadow agent and shadow port setup.
3. What the features need to be implemented to the Tricircle
to realize the solution?
This is the forth patch for cross-pod VxLAN networking support, which
introduces the following changes:
(1) Make bridge network gateway port creation also trigger shadow
agent and shadow port setup, so we can use VxLAN type bridge network
(2) Delete shadow bridge ports when clearing bridge network/subnet
[1] https://review.openstack.org/#/c/429155/
[2] https://review.openstack.org/#/c/425128/
[3] https://review.openstack.org/#/c/425129/
[4] https://review.openstack.org/#/c/425130/
Change-Id: I3f3054c9300566ddbdd5b6d523f547485462447c
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?
The detailed discussion of the proposals to support cross-pod VxLAN
network is covered in this specification.
3. What features need to be implemented to the Tricircle
to realize the solution?
The proposed changes in this specification need to be implemented.
Change-Id: I79b41a63778660bd5a7b6e5e3d66ce0bd394e9af
1. What is the problem
In tricircle/xjob/xmanager.py, there are two places that the note
descriptions are inconsistent with their implementations. For detailed
information, please see the bug report[1].
2. What is the solution for the problem
Modify the notes and keep them consistent with the implementations.
3. What the features need to be implemented to the Tricircle to
realize the solution
None.
[1] https://bugs.launchpad.net/tricircle/+bug/1674975
Change-Id: I5a56bd3343c37f607e42defc511e41f31a2d54ad
Closes-Bug: #1674975
1. What is the problem?
Currently, the allowed-address-pairs is not supported in the Tricircle.
2. What is the solution to the problem?
Enable allowed address pairs in central neutron.
3. What the features to be implemented in the Tricircle
to realize the solution?
No new features.
Change-Id: I5c4f1bf1b146d5fdf49c14d43f7226d81770e667
1. What is the problem
When XJob receives a job message from service, it will register
the job in database and handle it asynchronously. Tricircle
need to provide API for users to query the job status and trigger
failed job if something happens unexpectedly. This patch provides
asynchronous job management specification, then we will develop
relevant API to manage the job according to this specification.
2. What is the solution for the problem
The new features functioning as job management APIs are covered
in this specification.
3. What the features need to be implemented to the Tricircle to
realize the solution
These asynchronous job management APIs in this specification need
to be implemented.
Change-Id: I58df65b042a8866c4d8d7f5a65a3f85bcf43b62b
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.
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].
With the previous parts[2, 3], we can create instances in the same
VxLAN network but in different pods. With the help of shadow ports,
tunnels are correctly created so instances can communicate with each
other. But we have a problem during the association of a floating ip
with an instance port because "setup_bottom_router" job will also
create shadow port for floating ip association.
2. What is the solution to the problem?
Let "setup_bottom_router" and "setup_shadow_ports" jobs call the
same method to create shadow ports and handle conflict in that method.
3. What the features need to be implemented to the Tricircle
to realize the solution?
This is the third patch for cross-pod VxLAN networking support, which
introduces the following changes:
(1) Both creating floating ip and booting instance in vxlan network
will create shadow port, so we leave shadow port deletion work to
central plugin, it will delete shadow port when deleting instance port
With this patch, floating ip binding to the port which is from cross-pod
VxLAN network is supported.
[1] https://review.openstack.org/#/c/429155/
[2] https://review.openstack.org/#/c/425128/
[3] https://review.openstack.org/#/c/425129/
Change-Id: I7ca3e124232baf265ec5a8ed3df0aca1303a2ff7
1. What is the problem
central plugin is missing the get_router_availability_zones
function
2. What is the solution to the problem
Add get_router_availability_zones func to central plugin.
This function was added to its parent class
RouterAvailabilityZoneMixin(which is Neutron code) by
mistake in the previous test so I didn't find out
this problem.
3. What the features need to be implemented to the Tricircle
No new features
Change-Id: Ia2323478d319ead69ff4bbbdb46684b4f18340ad
1. What is the problem?
All the methods of XJobAPI is sharing common functionality which
can be simplify it.
2. What is the solution for the problem?
Refactoring those methods as much as possible
3. What the features need to be implemented to the Tricircle to
realize the solution?
None
TrivialFix
Change-Id: I3967ae66d744ad4b00f283306c911657c5735dae
1. What is the problem
Pod_id is a foreign key in cached_endpoints table and resource_routings
table, it references pod_id in pod table but has different length. For
more detailed information, please see the bug at the bottom.
2. What is the solution for the problem
Change pod_id length in cached_endpoints table and resource_routings
table. For these two tables in migration scripts we use script to
alter the pod_id length.
3. What the features need to be implemented to the Tricircle to
realize the solution
None.
Change-Id: I5ccfc2b72bcac2793c0901fd90c78edce181c074
Closes-Bug: #1670228
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.
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].
In part1[2], we have added the necessary logic to retrieve agent info
from local Neutron and save it in the shadow agent table in central
Neutron. Now we need to utilize this info to create shadow agent and
shadow port.
2. What is the solution to the problem?
An asynchronous job triggered when instance port is updated to active
is added. It calculates needed shadow ports and then create them in
the target pod.
3. What the features need to be implemented to the Tricircle
to realize the solution?
This is the second patch for cross-pod VxLAN networking support, which
introduces the following changes:
(1) A new asynchronous job setup_shadow_ports is added. Each asynchronous
job only handles the shadow ports setup in one given pod for one given
network. If shadow ports in other pod also needs to be updated, the job
registers one new job for each pod.
[1] https://review.openstack.org/#/c/429155/
[2] https://review.openstack.org/#/c/425128/
Change-Id: I9481016b54feb57aacd03688de882b8912a78018
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?
There is no mechaninsm to guarantee if the percentage of Unit Tests
is reduced after submitting a patch.
2. What is the solution to the problem?
Add a threshold into the gate job for ensuring a minimal percentage
3. What the features need to be implemented to the Tricircle
to realize the solution?
None
Change-Id: I478d2ba2b9d60867ac3a48ddb19d8cb33ee67301
1. What is the problem
1) Tricircle does not enable router's az
2) Tricircle's network topology is too complex for local
router(router reside only in one region)
2. What is the solution to the problem
1) Enable router's az
2) Remove ns-router and bridge network when used local router
3. What the features need to be implemented to the Tricircle
1)Enable router's az
2)Attach external network to local router directly, no additional
intermediate router is needed.
Implements: blueprint enable-router-az-simplify-net-top
Change-Id: I410a81c9d0e56db8163e611211b8dbd4c5772767
1. What is the problem
In delete_network, NeutronDbPluginV2 will notify network precommit-delete
event which is subscribed by SegmentDbMixin. While handling the event,
SegmentDbMixin tries to access 'description' field of Segment object in
get_segments function and fails. Therefore unit test fails.
2. What is the solution for the problem
In FakeSession, extend standard attributes for newly added object, which
include 'description'.
3. What the features need to be implemented to the Tricircle to
realize the solution
N/A.
Change-Id: Ib099f0a5616f25b47ae881e784d49ec739bca8bc
1. What is the problem
Neutron has rehomed the context to the neutron_lib, this will leads
to the test_central_plugin failed due to unreachble neutron.context,
and then all py27, py35 and coverage gate/check test will be failed
too, blocking all new patch to be merged.
2. What is the solution for the problem
Import context from neutron_lib
3. What the features need to be implemented to the Tricircle to
realize the solution
N/A.
Change-Id: I8f8eb8eaa43c669fdad2ce658dd58b1109ead46c
Signed-off-by: joehuang <joehuang@huawei.com>
1. What is the problem?
The older hacking library has a cap on pbr <2.0, which is causing
issues with the recent 2.0.0 release of pbr
2. What is the solution for the problem?
Hacking isn't kept in sync via the usual proposal bot updates so
update it manually to fix the pep8 gate.
3. What the features need to be implemented to the Tricircle to
realize the solution?
None
Partial-Bug: #1668848
Change-Id: I805565843c9228b729e242c3f2fddf14b6a3130e
1. What is the problem
In the enhance-xjob-reliability.rst, there are some
grammar errors and unnecessary characters. They are
reported as a bug(please see it at the bottom).
2. What is the solution for the problem
Correct the grammar errors and remove the unnecessary
characters.
3. What the features need to be implemented to the Tricircle to
realize the solution
None.
Change-Id: If5a1540ce2ac4f7e416ee3070b558346a578fe1d
Closes-Bug: #1667869
1. What is the problem
When resource routing needs to update its attribute
named pod_id, it will fail if the pod where the new pod_id
lays on doesn't exist. This update error was caught
through internal server error originally and it was not
detailed enough.
2. What is the solution for the problem
Dismiss this update request by giving a regular invalid
parameter error and tell the operator that the new pod
for resource routing should exist. The pod to which the
pod_id belongs can only be selected from the existing
pods. Because it is a foreign key and highly depends on
pod table. At the same time, we should add one test case
for this circumstance.
3. What the features need to be implemented to the Tricircle to
realize the solution
None.
Change-Id: Iae6e3368c7f0ff0cd751aca932cba818328bb723
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
Tricircle does not have get pod unit test case
2. What is the solution to the problem
Implement related test case
3. What the features need to be implemented to the Tricircle
No new features
Change-Id: Icf68127871d3c3393f43d54ee0a853215c6bad2f
1. What is the problem
Tricircle does not have update pod unit test case
2. What is the solution to the problem
Implement related test case
3. What the features need to be implemented to the Tricircle
No new features
Change-Id: Ifdfa599fb3ebe78ee5810066c885f4f84e4050c4
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
Tricircle does not have delete mappings unit test case
2. What is the solution to the problem
Implement related test case
3. What the features need to be implemented to the Tricircle
No new features
Change-Id: I597a25e4dbf0794a5dde4968db502672a28f4563
1. What is the problem
There is consideration on how to use availability zone hint
in Tricircle, currently only external network is described
in release notes.
2. What is the solution to the problem
Add availability zone hint related release notes for
general network.
3. What the features need to be implemented to the Tricircle
No new features
Change-Id: I4c0f69f573dc4b6bab070d5ea1b6c6dfdbf6222f
Signed-off-by: joehuang <joehuang@huawei.com>
