Creating ports in bulks can be very slow due to many IPAM module conflicts
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Medium
|
Slawek Kaplonski |
Bug Description
When ports are created in bulk, ML2 plugin tries to do everything for all ports in one single DB transaction. That means, that if IP allocation for one of the IPs will fail, whole create_port_bulk method will be retried so it will retry to do everything for all ports.
That may be very inefficient in some use cases, where many ports in bulk are created in same network.
I did simple test:
- create 2 networks with /24 subnet in each network,
- run 24 API requests to create 10 ports in bulk in each request - so in total 240 IPs from subnet will be allocated. All those requests were done in parallel.
- wait how long it will take to have all ports created.
I run my reproducer script 10 times as ipam module is working in some kind of random way so results may be different in various runs.
Results of that simple test are below:
Run Execution time
1 00:01:37
2 00:02:06
3 00:02:08
4 00:02:14
5 00:01:58
6 00:02:37
7 00:01:59
8 00:02:01
9 00:02:39
10 00:01:59
AVG 00:02:07
The execution time here is in fact time of the execution of the longest API request (all of them started together). So there was many retries done internally in Neutron to allocate IP addresses for those ports and client had to wait sometimes more than 150 seconds to get reply for request.
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master) | #1 |
Changed in neutron: | |
status: | Confirmed → In Progress |
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master) | #2 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: master
commit 82aabb0aa962a3c
Author: Slawek Kaplonski <email address hidden>
Date: Tue Dec 14 12:44:31 2021 +0100
Allocate IPs in bulk requests in separate transactions
In the ML2 plugin in create_port_bulk method, we are iterating over
list of the ports to be created and do everything for all ports in
single DB transaction (which makes totally sense as this is bulk
request).
But one of the things which was done during that huge transaction was
allocation of the IP addresses for all ports. That action is prone for
race conditions and can fail often, especially when there is no many IP
addresses available in the subnet(s) for the ports.
In case of the error while allocating IP address even for one port from
the whole bulk request, whole create_port_bulk method was retried so
allocations (and everything else) for all ports was reverted and started
from scratch. That takes a lot of time so some requests may be processed
very long time, like e.g. 2-3 minutes in my tests.
To reproduce that issue I did simple script which created network with
/24 subnet and then sent 24 requests to create 10 ports in bulk in each
request. That was in totall 240 ports created in that subnet.
I measured time of the creation of all those ports in the current master
branch (without this patch) and with the patch. Results are like below:
+--
| Run | Master branch | This patch | Simulate bulk by creation |
| | [mm:ss] | [mm:ss] | of 10 ports one by one |
+--
| 1 | 01:37 | 01:02 | 00:57 |
| 2 | 02:06 | 00:40 | 01:03 |
| 3 | 02:08 | 00:41 | 00:59 |
| 4 | 02:14 | 00:45 | 00:55 |
| 5 | 01:58 | 00:45 | 00:57 |
| 6 | 02:37 | 00:53 | 01:05 |
| 7 | 01:59 | 00:42 | 00:58 |
| 8 | 02:01 | 00:41 | 00:57 |
| 9 | 02:39 | 00:42 | 00:55 |
| 10 | 01:59 | 00:41 | 00:56 |
+--
| AVG | 00:02:07 | 00:00:45 | 00:58 |
+--
Closes-Bug: #1954763
Change-Id: I8877c658446fed
Changed in neutron: | |
status: | In Progress → Fix Released |
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/xena) | #3 |
Fix proposed to branch: stable/xena
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/wallaby) | #4 |
Fix proposed to branch: stable/wallaby
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/victoria) | #5 |
Fix proposed to branch: stable/victoria
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/ussuri) | #6 |
Fix proposed to branch: stable/ussuri
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/train) | #7 |
Fix proposed to branch: stable/train
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/wallaby) | #8 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/wallaby
commit 5e30cb5e2402308
Author: Slawek Kaplonski <email address hidden>
Date: Tue Dec 14 12:44:31 2021 +0100
Allocate IPs in bulk requests in separate transactions
In the ML2 plugin in create_port_bulk method, we are iterating over
list of the ports to be created and do everything for all ports in
single DB transaction (which makes totally sense as this is bulk
request).
But one of the things which was done during that huge transaction was
allocation of the IP addresses for all ports. That action is prone for
race conditions and can fail often, especially when there is no many IP
addresses available in the subnet(s) for the ports.
In case of the error while allocating IP address even for one port from
the whole bulk request, whole create_port_bulk method was retried so
allocations (and everything else) for all ports was reverted and started
from scratch. That takes a lot of time so some requests may be processed
very long time, like e.g. 2-3 minutes in my tests.
To reproduce that issue I did simple script which created network with
/24 subnet and then sent 24 requests to create 10 ports in bulk in each
request. That was in totall 240 ports created in that subnet.
I measured time of the creation of all those ports in the current master
branch (without this patch) and with the patch. Results are like below:
+--
| Run | Master branch | This patch | Simulate bulk by creation |
| | [mm:ss] | [mm:ss] | of 10 ports one by one |
+--
| 1 | 01:37 | 01:02 | 00:57 |
| 2 | 02:06 | 00:40 | 01:03 |
| 3 | 02:08 | 00:41 | 00:59 |
| 4 | 02:14 | 00:45 | 00:55 |
| 5 | 01:58 | 00:45 | 00:57 |
| 6 | 02:37 | 00:53 | 01:05 |
| 7 | 01:59 | 00:42 | 00:58 |
| 8 | 02:01 | 00:41 | 00:57 |
| 9 | 02:39 | 00:42 | 00:55 |
| 10 | 01:59 | 00:41 | 00:56 |
+--
| AVG | 00:02:07 | 00:00:45 | 00:58 |
+--
Closes-Bug: #1954763
Change-Id: I8877c658446fed
(cherry picked from commit 82aabb0aa962a3c
tags: | added: in-stable-wallaby |
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/victoria) | #9 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/victoria
commit f830dd3f335ab8a
Author: Slawek Kaplonski <email address hidden>
Date: Tue Dec 14 12:44:31 2021 +0100
Allocate IPs in bulk requests in separate transactions
In the ML2 plugin in create_port_bulk method, we are iterating over
list of the ports to be created and do everything for all ports in
single DB transaction (which makes totally sense as this is bulk
request).
But one of the things which was done during that huge transaction was
allocation of the IP addresses for all ports. That action is prone for
race conditions and can fail often, especially when there is no many IP
addresses available in the subnet(s) for the ports.
In case of the error while allocating IP address even for one port from
the whole bulk request, whole create_port_bulk method was retried so
allocations (and everything else) for all ports was reverted and started
from scratch. That takes a lot of time so some requests may be processed
very long time, like e.g. 2-3 minutes in my tests.
To reproduce that issue I did simple script which created network with
/24 subnet and then sent 24 requests to create 10 ports in bulk in each
request. That was in totall 240 ports created in that subnet.
I measured time of the creation of all those ports in the current master
branch (without this patch) and with the patch. Results are like below:
+--
| Run | Master branch | This patch | Simulate bulk by creation |
| | [mm:ss] | [mm:ss] | of 10 ports one by one |
+--
| 1 | 01:37 | 01:02 | 00:57 |
| 2 | 02:06 | 00:40 | 01:03 |
| 3 | 02:08 | 00:41 | 00:59 |
| 4 | 02:14 | 00:45 | 00:55 |
| 5 | 01:58 | 00:45 | 00:57 |
| 6 | 02:37 | 00:53 | 01:05 |
| 7 | 01:59 | 00:42 | 00:58 |
| 8 | 02:01 | 00:41 | 00:57 |
| 9 | 02:39 | 00:42 | 00:55 |
| 10 | 01:59 | 00:41 | 00:56 |
+--
| AVG | 00:02:07 | 00:00:45 | 00:58 |
+--
Closes-Bug: #1954763
Change-Id: I8877c658446fed
(cherry picked from commit 82aabb0aa962a3c
tags: | added: in-stable-victoria |
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/xena) | #10 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/xena
commit 56d2bda51d9750f
Author: Slawek Kaplonski <email address hidden>
Date: Tue Dec 14 12:44:31 2021 +0100
Allocate IPs in bulk requests in separate transactions
In the ML2 plugin in create_port_bulk method, we are iterating over
list of the ports to be created and do everything for all ports in
single DB transaction (which makes totally sense as this is bulk
request).
But one of the things which was done during that huge transaction was
allocation of the IP addresses for all ports. That action is prone for
race conditions and can fail often, especially when there is no many IP
addresses available in the subnet(s) for the ports.
In case of the error while allocating IP address even for one port from
the whole bulk request, whole create_port_bulk method was retried so
allocations (and everything else) for all ports was reverted and started
from scratch. That takes a lot of time so some requests may be processed
very long time, like e.g. 2-3 minutes in my tests.
To reproduce that issue I did simple script which created network with
/24 subnet and then sent 24 requests to create 10 ports in bulk in each
request. That was in totall 240 ports created in that subnet.
I measured time of the creation of all those ports in the current master
branch (without this patch) and with the patch. Results are like below:
+--
| Run | Master branch | This patch | Simulate bulk by creation |
| | [mm:ss] | [mm:ss] | of 10 ports one by one |
+--
| 1 | 01:37 | 01:02 | 00:57 |
| 2 | 02:06 | 00:40 | 01:03 |
| 3 | 02:08 | 00:41 | 00:59 |
| 4 | 02:14 | 00:45 | 00:55 |
| 5 | 01:58 | 00:45 | 00:57 |
| 6 | 02:37 | 00:53 | 01:05 |
| 7 | 01:59 | 00:42 | 00:58 |
| 8 | 02:01 | 00:41 | 00:57 |
| 9 | 02:39 | 00:42 | 00:55 |
| 10 | 01:59 | 00:41 | 00:56 |
+--
| AVG | 00:02:07 | 00:00:45 | 00:58 |
+--
Closes-Bug: #1954763
Change-Id: I8877c658446fed
(cherry picked from commit 82aabb0aa962a3c
tags: | added: in-stable-xena |
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/ussuri) | #11 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/ussuri
commit 5595239435f7999
Author: Slawek Kaplonski <email address hidden>
Date: Tue Dec 14 12:44:31 2021 +0100
Allocate IPs in bulk requests in separate transactions
In the ML2 plugin in create_port_bulk method, we are iterating over
list of the ports to be created and do everything for all ports in
single DB transaction (which makes totally sense as this is bulk
request).
But one of the things which was done during that huge transaction was
allocation of the IP addresses for all ports. That action is prone for
race conditions and can fail often, especially when there is no many IP
addresses available in the subnet(s) for the ports.
In case of the error while allocating IP address even for one port from
the whole bulk request, whole create_port_bulk method was retried so
allocations (and everything else) for all ports was reverted and started
from scratch. That takes a lot of time so some requests may be processed
very long time, like e.g. 2-3 minutes in my tests.
To reproduce that issue I did simple script which created network with
/24 subnet and then sent 24 requests to create 10 ports in bulk in each
request. That was in totall 240 ports created in that subnet.
I measured time of the creation of all those ports in the current master
branch (without this patch) and with the patch. Results are like below:
+--
| Run | Master branch | This patch | Simulate bulk by creation |
| | [mm:ss] | [mm:ss] | of 10 ports one by one |
+--
| 1 | 01:37 | 01:02 | 00:57 |
| 2 | 02:06 | 00:40 | 01:03 |
| 3 | 02:08 | 00:41 | 00:59 |
| 4 | 02:14 | 00:45 | 00:55 |
| 5 | 01:58 | 00:45 | 00:57 |
| 6 | 02:37 | 00:53 | 01:05 |
| 7 | 01:59 | 00:42 | 00:58 |
| 8 | 02:01 | 00:41 | 00:57 |
| 9 | 02:39 | 00:42 | 00:55 |
| 10 | 01:59 | 00:41 | 00:56 |
+--
| AVG | 00:02:07 | 00:00:45 | 00:58 |
+--
Closes-Bug: #1954763
Change-Id: I8877c658446fed
(cherry picked from commit 82aabb0aa962a3c
tags: | added: in-stable-ussuri |
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 17.3.0 | #12 |
This issue was fixed in the openstack/neutron 17.3.0 release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 18.2.0 | #13 |
This issue was fixed in the openstack/neutron 18.2.0 release.
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/train) | #14 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/train
commit 8ca6771d6174e64
Author: Slawek Kaplonski <email address hidden>
Date: Tue Dec 14 12:44:31 2021 +0100
Allocate IPs in bulk requests in separate transactions
In the ML2 plugin in create_port_bulk method, we are iterating over
list of the ports to be created and do everything for all ports in
single DB transaction (which makes totally sense as this is bulk
request).
But one of the things which was done during that huge transaction was
allocation of the IP addresses for all ports. That action is prone for
race conditions and can fail often, especially when there is no many IP
addresses available in the subnet(s) for the ports.
In case of the error while allocating IP address even for one port from
the whole bulk request, whole create_port_bulk method was retried so
allocations (and everything else) for all ports was reverted and started
from scratch. That takes a lot of time so some requests may be processed
very long time, like e.g. 2-3 minutes in my tests.
To reproduce that issue I did simple script which created network with
/24 subnet and then sent 24 requests to create 10 ports in bulk in each
request. That was in totall 240 ports created in that subnet.
I measured time of the creation of all those ports in the current master
branch (without this patch) and with the patch. Results are like below:
+--
| Run | Master branch | This patch | Simulate bulk by creation |
| | [mm:ss] | [mm:ss] | of 10 ports one by one |
+--
| 1 | 01:37 | 01:02 | 00:57 |
| 2 | 02:06 | 00:40 | 01:03 |
| 3 | 02:08 | 00:41 | 00:59 |
| 4 | 02:14 | 00:45 | 00:55 |
| 5 | 01:58 | 00:45 | 00:57 |
| 6 | 02:37 | 00:53 | 01:05 |
| 7 | 01:59 | 00:42 | 00:58 |
| 8 | 02:01 | 00:41 | 00:57 |
| 9 | 02:39 | 00:42 | 00:55 |
| 10 | 01:59 | 00:41 | 00:56 |
+--
| AVG | 00:02:07 | 00:00:45 | 00:58 |
+--
Conflicts:
Closes-Bug: #1954763
Change-Id: I8877c658446fed
(cherry picked from commit 82aabb0aa962a3c
(cherry picked from commit 5595239435f7999
tags: | added: in-stable-train |
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 20.0.0.0rc1 | #15 |
This issue was fixed in the openstack/neutron 20.0.0.0rc1 release candidate.
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (master) | #16 |
Related fix proposed to branch: master
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/yoga) | #17 |
Related fix proposed to branch: stable/yoga
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/xena) | #18 |
Related fix proposed to branch: stable/xena
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/wallaby) | #19 |
Related fix proposed to branch: stable/wallaby
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/victoria) | #20 |
Related fix proposed to branch: stable/victoria
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/ussuri) | #21 |
Related fix proposed to branch: stable/ussuri
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/train) | #22 |
Related fix proposed to branch: stable/train
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (master) | #23 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: master
commit 83b6ce9e9ec2f02
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Wed Mar 16 16:32:31 2022 +0000
Remove exception ``IpAddressAllo
This patch removes the ``IpAddressAllo
exception was raised when a IPAM register was called to be deleted
but not found.
As reported in the LP bug, this IPAM register deletion can be called
several times if a port fails during the creation. The IPAM register
deletion calls the DB deletion but doesn't raise any exception if the
register does not exist. The code ensures the IPAM register is
deleted and there is no need to fail if it is not present anymore.
This patch also removes the exception catch and try in "update_port",
that was added in [0] as a fix for [1]. That was added because the
subnet deletion code involved a port update call [2] during the
IP allocation deletion, if any port was still present in the subnet.
Since [3], this code is not needed because the subnet deletion does
not call a port update anymore.
[0]https:/
[1]https:/
[2]https:/
[3]https:/
Closes-Bug: #1965807
Related-Bug: #1954763
Related-Bug: #1622616
Change-Id: I5b96b3a91aacff
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/yoga) | #24 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/yoga
commit 2a6a4ab5dacc2e9
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Wed Mar 16 16:32:31 2022 +0000
Remove exception ``IpAddressAllo
This patch removes the ``IpAddressAllo
exception was raised when a IPAM register was called to be deleted
but not found.
As reported in the LP bug, this IPAM register deletion can be called
several times if a port fails during the creation. The IPAM register
deletion calls the DB deletion but doesn't raise any exception if the
register does not exist. The code ensures the IPAM register is
deleted and there is no need to fail if it is not present anymore.
This patch also removes the exception catch and try in "update_port",
that was added in [0] as a fix for [1]. That was added because the
subnet deletion code involved a port update call [2] during the
IP allocation deletion, if any port was still present in the subnet.
Since [3], this code is not needed because the subnet deletion does
not call a port update anymore.
[0]https:/
[1]https:/
[2]https:/
[3]https:/
Closes-Bug: #1965807
Related-Bug: #1954763
Related-Bug: #1622616
Conflicts:
Change-Id: I5b96b3a91aacff
(cherry picked from commit 83b6ce9e9ec2f02
tags: | added: in-stable-yoga |
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/xena) | #25 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/xena
commit d2b1e3edaafdf5a
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Wed Mar 16 16:32:31 2022 +0000
Remove exception ``IpAddressAllo
This patch removes the ``IpAddressAllo
exception was raised when a IPAM register was called to be deleted
but not found.
As reported in the LP bug, this IPAM register deletion can be called
several times if a port fails during the creation. The IPAM register
deletion calls the DB deletion but doesn't raise any exception if the
register does not exist. The code ensures the IPAM register is
deleted and there is no need to fail if it is not present anymore.
This patch also removes the exception catch and try in "update_port",
that was added in [0] as a fix for [1]. That was added because the
subnet deletion code involved a port update call [2] during the
IP allocation deletion, if any port was still present in the subnet.
Since [3], this code is not needed because the subnet deletion does
not call a port update anymore.
[0]https:/
[1]https:/
[2]https:/
[3]https:/
Closes-Bug: #1965807
Related-Bug: #1954763
Related-Bug: #1622616
Conflicts:
Change-Id: I5b96b3a91aacff
(cherry picked from commit 83b6ce9e9ec2f02
(cherry picked from commit 2a6a4ab5dacc2e9
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/wallaby) | #26 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/wallaby
commit b053dfe3844aaf0
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Wed Mar 16 16:32:31 2022 +0000
Remove exception ``IpAddressAllo
This patch removes the ``IpAddressAllo
exception was raised when a IPAM register was called to be deleted
but not found.
As reported in the LP bug, this IPAM register deletion can be called
several times if a port fails during the creation. The IPAM register
deletion calls the DB deletion but doesn't raise any exception if the
register does not exist. The code ensures the IPAM register is
deleted and there is no need to fail if it is not present anymore.
This patch also removes the exception catch and try in "update_port",
that was added in [0] as a fix for [1]. That was added because the
subnet deletion code involved a port update call [2] during the
IP allocation deletion, if any port was still present in the subnet.
Since [3], this code is not needed because the subnet deletion does
not call a port update anymore.
[0]https:/
[1]https:/
[2]https:/
[3]https:/
Closes-Bug: #1965807
Related-Bug: #1954763
Related-Bug: #1622616
Conflicts:
Change-Id: I5b96b3a91aacff
(cherry picked from commit 83b6ce9e9ec2f02
(cherry picked from commit 2a6a4ab5dacc2e9
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/victoria) | #27 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/victoria
commit 884418183a6e518
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Wed Mar 16 16:32:31 2022 +0000
Remove exception ``IpAddressAllo
This patch removes the ``IpAddressAllo
exception was raised when a IPAM register was called to be deleted
but not found.
As reported in the LP bug, this IPAM register deletion can be called
several times if a port fails during the creation. The IPAM register
deletion calls the DB deletion but doesn't raise any exception if the
register does not exist. The code ensures the IPAM register is
deleted and there is no need to fail if it is not present anymore.
This patch also removes the exception catch and try in "update_port",
that was added in [0] as a fix for [1]. That was added because the
subnet deletion code involved a port update call [2] during the
IP allocation deletion, if any port was still present in the subnet.
Since [3], this code is not needed because the subnet deletion does
not call a port update anymore.
[0]https:/
[1]https:/
[2]https:/
[3]https:/
Closes-Bug: #1965807
Related-Bug: #1954763
Related-Bug: #1622616
Conflicts:
Change-Id: I5b96b3a91aacff
(cherry picked from commit 83b6ce9e9ec2f02
(cherry picked from commit 2a6a4ab5dacc2e9
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/ussuri) | #28 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/ussuri
commit 4f03e76aaafbbc8
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Wed Mar 16 16:32:31 2022 +0000
Remove exception ``IpAddressAllo
This patch removes the ``IpAddressAllo
exception was raised when a IPAM register was called to be deleted
but not found.
As reported in the LP bug, this IPAM register deletion can be called
several times if a port fails during the creation. The IPAM register
deletion calls the DB deletion but doesn't raise any exception if the
register does not exist. The code ensures the IPAM register is
deleted and there is no need to fail if it is not present anymore.
This patch also removes the exception catch and try in "update_port",
that was added in [0] as a fix for [1]. That was added because the
subnet deletion code involved a port update call [2] during the
IP allocation deletion, if any port was still present in the subnet.
Since [3], this code is not needed because the subnet deletion does
not call a port update anymore.
[0]https:/
[1]https:/
[2]https:/
[3]https:/
Closes-Bug: #1965807
Related-Bug: #1954763
Related-Bug: #1622616
Conflicts:
Change-Id: I5b96b3a91aacff
(cherry picked from commit 83b6ce9e9ec2f02
(cherry picked from commit 2a6a4ab5dacc2e9
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/train) | #29 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/train
commit 1254f2371864e10
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Wed Mar 16 16:32:31 2022 +0000
Remove exception ``IpAddressAllo
This patch removes the ``IpAddressAllo
exception was raised when a IPAM register was called to be deleted
but not found.
As reported in the LP bug, this IPAM register deletion can be called
several times if a port fails during the creation. The IPAM register
deletion calls the DB deletion but doesn't raise any exception if the
register does not exist. The code ensures the IPAM register is
deleted and there is no need to fail if it is not present anymore.
This patch also removes the exception catch and try in "update_port",
that was added in [0] as a fix for [1]. That was added because the
subnet deletion code involved a port update call [2] during the
IP allocation deletion, if any port was still present in the subnet.
Since [3], this code is not needed because the subnet deletion does
not call a port update anymore.
[0]https:/
[1]https:/
[2]https:/
[3]https:/
Closes-Bug: #1965807
Related-Bug: #1954763
Related-Bug: #1622616
Conflicts:
Change-Id: I5b96b3a91aacff
(cherry picked from commit 83b6ce9e9ec2f02
(cherry picked from commit 2a6a4ab5dacc2e9
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 19.2.0 | #30 |
This issue was fixed in the openstack/neutron 19.2.0 release.
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (master) | #31 |
Related fix proposed to branch: master
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (master) | #32 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: master
commit f7dd7790f5c6e31
Author: elajkat <email address hidden>
Date: Fri Nov 4 16:51:03 2022 +0100
Fix bulk create without mac
Bulk port create without mac address fails as when Neutron calls
oslo_
is an ATTR_NOT_SPECIFIED Sentinel() object.
With some reshuffling of the code to fill the mac field this can be
fixed.
Closes-Bug: #1995732
Related-Bug: #1954763
Change-Id: Id594003681f475
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/zed) | #33 |
Related fix proposed to branch: stable/zed
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/yoga) | #34 |
Related fix proposed to branch: stable/yoga
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/zed) | #35 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/zed
commit c09f7ec2ee1ade6
Author: elajkat <email address hidden>
Date: Fri Nov 4 16:51:03 2022 +0100
Fix bulk create without mac
Bulk port create without mac address fails as when Neutron calls
oslo_
is an ATTR_NOT_SPECIFIED Sentinel() object.
With some reshuffling of the code to fill the mac field this can be
fixed.
Conflicts:
neutron/
Closes-Bug: #1995732
Related-Bug: #1954763
Change-Id: Id594003681f475
(cherry picked from commit f7dd7790f5c6e31
tags: | added: in-stable-zed |
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/yoga) | #36 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/yoga
commit 2ed8fa503759433
Author: elajkat <email address hidden>
Date: Fri Nov 4 16:51:03 2022 +0100
Fix bulk create without mac
Bulk port create without mac address fails as when Neutron calls
oslo_
is an ATTR_NOT_SPECIFIED Sentinel() object.
With some reshuffling of the code to fill the mac field this can be
fixed.
Conflicts:
neutron/
Closes-Bug: #1995732
Related-Bug: #1954763
Change-Id: Id594003681f475
(cherry picked from commit f7dd7790f5c6e31
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/xena) | #37 |
Related fix proposed to branch: stable/xena
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/wallaby) | #38 |
Related fix proposed to branch: stable/wallaby
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/xena) | #39 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/xena
commit ffd749689567925
Author: elajkat <email address hidden>
Date: Fri Nov 4 16:51:03 2022 +0100
Fix bulk create without mac
Bulk port create without mac address fails as when Neutron calls
oslo_
is an ATTR_NOT_SPECIFIED Sentinel() object.
With some reshuffling of the code to fill the mac field this can be
fixed.
Conflicts:
neutron/
Closes-Bug: #1995732
Related-Bug: #1954763
Change-Id: Id594003681f475
(cherry picked from commit f7dd7790f5c6e31
(cherry picked from commit 2ed8fa503759433
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/wallaby) | #40 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/wallaby
commit 2c854cff4d39dbc
Author: elajkat <email address hidden>
Date: Fri Nov 4 16:51:03 2022 +0100
Fix bulk create without mac
Bulk port create without mac address fails as when Neutron calls
oslo_
is an ATTR_NOT_SPECIFIED Sentinel() object.
With some reshuffling of the code to fill the mac field this can be
fixed.
Conflicts:
neutron/
neutron_
was only introduced in Xena
Closes-Bug: #1995732
Related-Bug: #1954763
Change-Id: Id594003681f475
(cherry picked from commit f7dd7790f5c6e31
(cherry picked from commit 2ed8fa503759433
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron train-eol | #41 |
This issue was fixed in the openstack/neutron train-eol release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron ussuri-eol | #42 |
This issue was fixed in the openstack/neutron ussuri-eol release.
Fix proposed to branch: master /review. opendev. org/c/openstack /neutron/ +/821727
Review: https:/