| 2019-07-17 05:17:07 |
qinhaizhong |
bug |
|
|
added bug |
| 2019-07-17 05:17:49 |
qinhaizhong |
neutron: assignee |
|
qinhaizhong (qinhaizhong) |
|
| 2019-07-17 05:25:20 |
qinhaizhong |
neutron: status |
New |
In Progress |
|
| 2019-07-17 05:28:06 |
qinhaizhong |
description |
When the virtual machines are created in batches, nova will call the neutron API to create the port concurrently. When an ip allocation conflict fails to submit a database, a ``DB ERROR`` exception is thrown. ``Create_port`` will catch the above exception and rest after ``retry_interval=0.1`` and re-call ``create_port`` until it exceeds ``max_retries=10``.When it exceeds ``max_retries=10`` times, "Create_port" will fail. And bulk create port has similar problem.
The current design using the retry mechanism will cause the neutron burden to burst rapidly. At this time, the api that calls neutron will not be able to get the corresponding 60 seconds. The caller will judge that the neutron api fails to be called, which causes various problems.
Details see https://bugs.launchpad.net/neutron/+bug/1777968.And bulk port creation has the same problem.
We will implements a new ipam driver by introducing a distributed lock to completely solve the problem of ip address allocation conflict leading to failure. And Distributed locks we will use openstack tooz, which supports many backend
drivers, such as Zookeeper, Memcached, Redis, Mysql, etc., and it is an openstack native project. |
When the virtual machines are created in batches, nova will call the neutron API to create the port concurrently. When an ip allocation conflict fails to submit a database, a ``DB ERROR`` exception is thrown. ``Create_port`` will catch the above exception and rest after ``retry_interval=0.1`` and re-call ``create_port`` until it exceeds ``max_retries=10``.When it exceeds ``max_retries=10`` times, "Create_port" will fail. And bulk create port has similar problem.
The current design using the retry mechanism will cause the neutron burden to burst rapidly. At this time, the api that calls neutron will not be able to get the corresponding 60 seconds. The caller will judge that the neutron api fails to be called, which causes various problems.
Details see https://bugs.launchpad.net/neutron/+bug/1777968.And bulk port creation has the same problem.
We will implements a new ipam driver by introducing a distributed lock to completely solve the problem of ip address allocation conflict leading to failure. And distributed locks we will use openstack tooz, which supports many backend
drivers, such as Zookeeper, Memcached, Redis, Mysql, etc., and it is an openstack native project. |
|
| 2019-07-17 05:34:11 |
qinhaizhong |
neutron: status |
In Progress |
New |
|
| 2019-07-17 05:46:20 |
qinhaizhong |
description |
When the virtual machines are created in batches, nova will call the neutron API to create the port concurrently. When an ip allocation conflict fails to submit a database, a ``DB ERROR`` exception is thrown. ``Create_port`` will catch the above exception and rest after ``retry_interval=0.1`` and re-call ``create_port`` until it exceeds ``max_retries=10``.When it exceeds ``max_retries=10`` times, "Create_port" will fail. And bulk create port has similar problem.
The current design using the retry mechanism will cause the neutron burden to burst rapidly. At this time, the api that calls neutron will not be able to get the corresponding 60 seconds. The caller will judge that the neutron api fails to be called, which causes various problems.
Details see https://bugs.launchpad.net/neutron/+bug/1777968.And bulk port creation has the same problem.
We will implements a new ipam driver by introducing a distributed lock to completely solve the problem of ip address allocation conflict leading to failure. And distributed locks we will use openstack tooz, which supports many backend
drivers, such as Zookeeper, Memcached, Redis, Mysql, etc., and it is an openstack native project. |
When the virtual machines are created in batches, nova will call the neutron API to create the port concurrently. When an ip allocation conflict fails to submit a database, a ``DB ERROR`` exception is thrown. ``Create_port`` will catch the above exception and rest after ``retry_interval=0.1`` and re-call ``create_port`` until it exceeds ``max_retries=10``.When it exceeds ``max_retries=10`` times, "Create_port" will fail. And bulk create port has similar problem.
The current design using the retry mechanism will cause the neutron burden to burst rapidly. At this time, the api that calls neutron will not be able to get the corresponding 60 seconds. The caller will judge that the neutron api fails to be called, which causes various problems.
Details see https://bugs.launchpad.net/neutron/+bug/1777968. And bulk port creation has the same problem.
We will implements a new ipam driver by introducing a distributed lock to completely solve the problem of ip address allocation conflict leading to failure. And distributed locks we will use openstack tooz, which supports many backend
drivers, such as Zookeeper, Memcached, Redis, Mysql, etc., and it is an openstack native project. |
|
| 2019-07-17 05:46:40 |
qinhaizhong |
description |
When the virtual machines are created in batches, nova will call the neutron API to create the port concurrently. When an ip allocation conflict fails to submit a database, a ``DB ERROR`` exception is thrown. ``Create_port`` will catch the above exception and rest after ``retry_interval=0.1`` and re-call ``create_port`` until it exceeds ``max_retries=10``.When it exceeds ``max_retries=10`` times, "Create_port" will fail. And bulk create port has similar problem.
The current design using the retry mechanism will cause the neutron burden to burst rapidly. At this time, the api that calls neutron will not be able to get the corresponding 60 seconds. The caller will judge that the neutron api fails to be called, which causes various problems.
Details see https://bugs.launchpad.net/neutron/+bug/1777968. And bulk port creation has the same problem.
We will implements a new ipam driver by introducing a distributed lock to completely solve the problem of ip address allocation conflict leading to failure. And distributed locks we will use openstack tooz, which supports many backend
drivers, such as Zookeeper, Memcached, Redis, Mysql, etc., and it is an openstack native project. |
When the virtual machines are created in batches, nova will call the neutron API to create the port concurrently. When an ip allocation conflict fails to submit a database, a ``DB ERROR`` exception is thrown. ``Create_port`` will catch the above exception and rest after ``retry_interval=0.1`` and re-call ``create_port`` until it exceeds ``max_retries=10``.When it exceeds ``max_retries=10`` times, "Create_port" will fail. And bulk create port has similar problem.
The current design using the retry mechanism will cause the neutron burden to burst rapidly. At this time, the api that calls neutron will not be able to get the corresponding 60 seconds. The caller will judge that the neutron api fails to be called, which causes various problems.
Details see https://bugs.launchpad.net/neutron/+bug/1777968. And bulk port creation has the same problem.
We will implements a new ipam driver by introducing a distributed lock to completely solve the problem of ip address allocation conflict leading to failure. And distributed locks we will use openstack tooz, which supports many backend
drivers, such as Zookeeper, Memcached, Redis, Mysql, etc. And it is an openstack native project. |
|
| 2019-07-17 06:36:44 |
qinhaizhong |
description |
When the virtual machines are created in batches, nova will call the neutron API to create the port concurrently. When an ip allocation conflict fails to submit a database, a ``DB ERROR`` exception is thrown. ``Create_port`` will catch the above exception and rest after ``retry_interval=0.1`` and re-call ``create_port`` until it exceeds ``max_retries=10``.When it exceeds ``max_retries=10`` times, "Create_port" will fail. And bulk create port has similar problem.
The current design using the retry mechanism will cause the neutron burden to burst rapidly. At this time, the api that calls neutron will not be able to get the corresponding 60 seconds. The caller will judge that the neutron api fails to be called, which causes various problems.
Details see https://bugs.launchpad.net/neutron/+bug/1777968. And bulk port creation has the same problem.
We will implements a new ipam driver by introducing a distributed lock to completely solve the problem of ip address allocation conflict leading to failure. And distributed locks we will use openstack tooz, which supports many backend
drivers, such as Zookeeper, Memcached, Redis, Mysql, etc. And it is an openstack native project. |
When the virtual machines are created in batches, nova will call the neutron API to create the port concurrently. When an ip allocation conflict fails to submit a database, a ``DB ERROR`` exception is thrown. ``Create_port`` will catch the above exception and rest after ``retry_interval=0.1`` and re-call ``create_port`` until it exceeds ``max_retries=10``.When it exceeds ``max_retries=10`` times, "Create_port" will fail. And bulk create port has similar problem.
The current design using the retry mechanism will cause the neutron burden to burst rapidly. At this time, the api that calls neutron will not be able to get the corresponding in 60 seconds. The caller will judge that the neutron api fails to be called, which will cause various problems.
Details see https://bugs.launchpad.net/neutron/+bug/1777968. And bulk port creation has the same problem.
We will implements a new ipam driver by introducing a distributed lock to completely solve the problem of ip address allocation conflict leading to failure. And distributed locks we will use openstack tooz, which supports many backend
drivers, such as Zookeeper, Memcached, Redis, Mysql, etc. And it is an openstack native project. |
|
| 2019-07-17 07:15:01 |
Brin Zhang |
tags |
rfe |
rfe-confirmed |
|
| 2019-07-17 07:17:18 |
Slawek Kaplonski |
tags |
rfe-confirmed |
rfe rfe-confirmed |
|
| 2019-07-17 07:52:21 |
qinhaizhong |
bug |
|
|
added subscriber Maciej Jozefczyk |
| 2019-07-18 00:42:43 |
Hongbin Lu |
neutron: status |
New |
Confirmed |
|
| 2019-07-18 00:42:46 |
Hongbin Lu |
neutron: importance |
Undecided |
Wishlist |
|
| 2019-07-19 04:40:36 |
qinhaizhong |
description |
When the virtual machines are created in batches, nova will call the neutron API to create the port concurrently. When an ip allocation conflict fails to submit a database, a ``DB ERROR`` exception is thrown. ``Create_port`` will catch the above exception and rest after ``retry_interval=0.1`` and re-call ``create_port`` until it exceeds ``max_retries=10``.When it exceeds ``max_retries=10`` times, "Create_port" will fail. And bulk create port has similar problem.
The current design using the retry mechanism will cause the neutron burden to burst rapidly. At this time, the api that calls neutron will not be able to get the corresponding in 60 seconds. The caller will judge that the neutron api fails to be called, which will cause various problems.
Details see https://bugs.launchpad.net/neutron/+bug/1777968. And bulk port creation has the same problem.
We will implements a new ipam driver by introducing a distributed lock to completely solve the problem of ip address allocation conflict leading to failure. And distributed locks we will use openstack tooz, which supports many backend
drivers, such as Zookeeper, Memcached, Redis, Mysql, etc. And it is an openstack native project. |
When the virtual machines are created in batches, nova will call the neutron API to create the port concurrently. When an ip allocation conflict fails to submit a database, a ``DB ERROR`` exception is thrown. ``Create_port`` will catch the above exception and rest after ``retry_interval=0.1`` and re-call ``create_port`` until it exceeds ``max_retries=10``.When it exceeds ``max_retries=10`` times, "Create_port" will fail. And bulk create port has similar problem.
The current design using the retry mechanism will cause the neutron burden to burst rapidly. At this time, the api that calls neutron will not be able to get the corresponding in 60 seconds. The caller will judge that the neutron api fails to be called, which will cause various problems.
Details see https://bugs.launchpad.net/neutron/+bug/1777968. And bulk port creation has the same problem.
We will implements a new ipam driver by introducing a distributed lock to completely solve the problem of ip address allocation conflict leading to failure. And distributed locks we will use openstack tooz, which supports many backend
drivers, such as Zookeeper, Memcached, Redis, Mysql, etc. And tooz is an openstack native project. |
|
| 2019-07-22 03:32:42 |
qinhaizhong |
removed subscriber Maciej Jozefczyk |
|
|
|
| 2019-07-22 03:34:02 |
qinhaizhong |
bug |
|
|
added subscriber Brin Zhang |
| 2019-07-22 03:34:30 |
qinhaizhong |
bug |
|
|
added subscriber ZhouHeng |
| 2019-07-22 03:35:11 |
qinhaizhong |
bug |
|
|
added subscriber Hongbin Lu |
| 2019-07-22 03:35:36 |
qinhaizhong |
bug |
|
|
added subscriber Miguel Lavalle |
| 2019-07-22 03:35:59 |
qinhaizhong |
bug |
|
|
added subscriber Slawek Kaplonski |
| 2019-07-26 00:19:18 |
Miguel Lavalle |
tags |
rfe rfe-confirmed |
rfe-triaged |
|
| 2019-08-09 21:15:58 |
Miguel Lavalle |
tags |
rfe-triaged |
rfe-approved |
|
