[Yahoo-eng-team] [Bug 2035573] [NEW] Insertion of a duplicated ProviderResourceAssociation entry while creating a HA router
Public bug reported:
[SUMMARY]
While creating multiple HA routers in a row, some router creations are failed
with the log below.
2023-07-21 02:28:19.968 12 DEBUG neutron.wsgi [-] (12) accepted ('10.2.41.158',
57438) server
/var/lib/kolla/venv/lib/python3.10/site-packages/eventlet/wsgi.py:1004
2023-07-21 02:28:19.979 12 DEBUG neutron.api.v2.base [None
req-726ab30e-b9c9-4e38-8c9d-216752ab2aea 439ae1ccaa9a494284cee3fdb6227208
97895007888245c3acdfc41146d2e151 - - default default] Request body: {'router':
{'name': 'test6', 'admin_state_up': True, 'tenant_id':
'97895007888245c3acdfc41146d2e151'}} prepare_request_body
/var/lib/kolla/venv/lib/python3.10/site-packages/neutron/api/v2/base.py:731
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db [None
req-726ab30e-b9c9-4e38-8c9d-216752ab2aea 439ae1ccaa9a494284cee3fdb6227208
97895007888245c3acdfc41146d2e151 - - default default] Failed to schedule HA
router 5a599ade-7b6a-4b3e-b635-ca00e37f2657.:
neutron_lib.objects.exceptions.NeutronDbObjectDuplicateEntry: Failed to create
a duplicate ProviderResourceAssociation: for attribute(s) ['PRIMARY'] with
value(s) ha-5a599ade-7b6a-4b3e-b635-ca00e37f2657
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db Traceback (most recent
call last):
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/engine/base.py",
line 1900, in _execute_context
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db
self.dialect.do_execute(
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/engine/default.py",
line 736, in do_execute
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db
cursor.execute(statement, parameters)
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/cursors.py", line
148, in execute
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db result =
self._query(query)
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/cursors.py", line
310, in _query
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db conn.query(q)
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line
548, in query
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db
self._affected_rows = self._read_query_result(unbuffered=unbuffered)
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line
775, in _read_query_result
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db result.read()
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line
1156, in read
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db first_packet =
self.connection._read_packet()
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line
725, in _read_packet
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db
packet.raise_for_error()
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/protocol.py", line
221, in raise_for_error
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db
err.raise_mysql_exception(self._data)
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/err.py", line 143, in
raise_mysql_exception
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db raise
errorclass(errno, errval)
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db
pymysql.err.IntegrityError: (1062, "Duplicate entry
'ha-5a599ade-7b6a-4b3e-b635-ca00e37f2657' for key 'PRIMARY'")
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db The above exception
was the direct cause of the following exception:
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db Traceback (most recent
call last):
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/neutron/objects/base.py",
line 903, in create
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db db_obj =
obj_db_api.create_object(
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
"/var/lib/kolla/venv/lib/python3.10/site-packages/neutron/objects/db/api.py",
line 72, in create_object
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db with
obj_cls.db_context_writer(context):
2023-07-21 02:28:20.178 12 ERROR neutron.db.l3_hamode_db File
[Yahoo-eng-team] [Bug 1943639] Re: project/instances/attach_interface has O(N) scaling time complexity for opening form
** Changed in: horizon (Ubuntu) Status: New => Fix Released ** Changed in: cloud-archive Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1943639 Title: project/instances/attach_interface has O(N) scaling time complexity for opening form Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive ussuri series: New Status in Ubuntu Cloud Archive victoria series: New Status in Ubuntu Cloud Archive wallaby series: New Status in Ubuntu Cloud Archive xena series: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in horizon package in Ubuntu: Fix Released Status in horizon source package in Focal: New Bug description: [ Impact ] The time complexity of opening the project/instances/attach_interface form box is O(N) where N is the number of networks in the project with a large prefactor. This is due to https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard/dashboards/project/instances/utils.py#L210 Which loops over the networks and requests the ports associated with the network. For large projects this scaling behavior can become prohibitive. The patch [1] addresses this issue by reducing the number of API calls and hence the prefactor of the algorithm. [ Test Plan ] In order to reproduce the issue, create a Nova VM and then add many networks. On the instances tab in the Horizon UI click on "attach interface" for the VM. It will take a moment for the dialog to appear. The exact time until the dialog appears will depend on the number of networks linearly. With [1] the time it takes for the dialog box to appear will be significantly shorter. [ Where problems could occur ] The patch [1] affects the "attach interface" dialog box and could break this UI feature in case something was wrong with the implementation. It is also possible that due to a bug in the implementation some networks are missing from the dialog. [1] https://review.opendev.org/c/openstack/horizon/+/866895 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1943639/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2035382] [NEW] [FT] "TestMonitorDaemon._run_monitor" failing radomly, initial message not written
Public bug reported: The method ``TestMonitorDaemon._run_monitor`` is randomly failing. The initial message expected after "keepalived_state_change" process is started is not written in the logs. Logs: https://8271f43479f81f7d3395-4bdeef087e9d95514555f2932706a956.ssl.cf1.rackcdn.com/893555/1/check/neutron- functional-with-uwsgi/90dde54/testr_results.html Snippet: https://paste.opendev.org/show/bJCAjIqiUOcWB0xBhPnX/ ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2035382 Title: [FT] "TestMonitorDaemon._run_monitor" failing radomly, initial message not written Status in neutron: New Bug description: The method ``TestMonitorDaemon._run_monitor`` is randomly failing. The initial message expected after "keepalived_state_change" process is started is not written in the logs. Logs: https://8271f43479f81f7d3395-4bdeef087e9d95514555f2932706a956.ssl.cf1.rackcdn.com/893555/1/check/neutron- functional-with-uwsgi/90dde54/testr_results.html Snippet: https://paste.opendev.org/show/bJCAjIqiUOcWB0xBhPnX/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2035382/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2035375] [NEW] Detaching multiple NVMe-oF volumes may leave the subsystem in connecting state
Public bug reported: When detaching multiple NVMe-oF volumes from the same host we may end with a NVMe subsystem in "connecting" state, and we'll see a bunch nvme error in dmesg. This happens on storage systems that share the same subsystem for multiple volumes because Nova has not been updated to support the tri- state "shared_targets" option that groups the detach and unmap of volumes to prevent race conditions. This is related to the issue mentioned in an os-brick commit message: https://review.opendev.org/c/openstack/os-brick/+/836062/12//COMMIT_MSG ** Affects: nova Importance: Undecided Assignee: Gorka Eguileor (gorka) Status: New ** Changed in: nova Assignee: (unassigned) => Gorka Eguileor (gorka) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2035375 Title: Detaching multiple NVMe-oF volumes may leave the subsystem in connecting state Status in OpenStack Compute (nova): New Bug description: When detaching multiple NVMe-oF volumes from the same host we may end with a NVMe subsystem in "connecting" state, and we'll see a bunch nvme error in dmesg. This happens on storage systems that share the same subsystem for multiple volumes because Nova has not been updated to support the tri- state "shared_targets" option that groups the detach and unmap of volumes to prevent race conditions. This is related to the issue mentioned in an os-brick commit message: https://review.opendev.org/c/openstack/os- brick/+/836062/12//COMMIT_MSG To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2035375/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2035368] [NEW] Debug config option in cinder and glance sections not working
Public bug reported: Nova has the hability of individually setting debug mode for cinder related libraries (cinderclient and os-brick) and for glanceclient using their respective configuration sections and setting `debug = true` regardless of the default debug setting. Unfortunately these options don't work as expected and have no effect. ** Affects: nova Importance: Undecided Assignee: Gorka Eguileor (gorka) Status: New ** Changed in: nova Assignee: (unassigned) => Gorka Eguileor (gorka) ** Description changed: - Nova has the possibility of individually setting debug mode for cinder + Nova has the hability of individually setting debug mode for cinder related libraries (cinderclient and os-brick) and for glanceclient using their respective configuration sections and setting `debug = true` regardless of the default debug setting. Unfortunately these options don't work as expected and have no effect. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2035368 Title: Debug config option in cinder and glance sections not working Status in OpenStack Compute (nova): New Bug description: Nova has the hability of individually setting debug mode for cinder related libraries (cinderclient and os-brick) and for glanceclient using their respective configuration sections and setting `debug = true` regardless of the default debug setting. Unfortunately these options don't work as expected and have no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2035368/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1999209] Re: Internal ip of FIP will not changed if updated fixed_ips of internal port
Reviewed: https://review.opendev.org/c/openstack/neutron/+/889791 Committed: https://opendev.org/openstack/neutron/commit/aad82233eb4fa7a6354f58cd9f8fda869f77db80 Submitter: "Zuul (22348)" Branch:master commit aad82233eb4fa7a6354f58cd9f8fda869f77db80 Author: liushy Date: Thu Jul 27 12:48:34 2023 +0800 Prevent internal IP change for floating IP Raise an error when deleting/changing the fixed IP which is linked to a floating IP. Closes-Bug: #1999209 Change-Id: I83a5b6c30d54435426f75f4cd1f80bf41822eec5 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1999209 Title: Internal ip of FIP will not changed if updated fixed_ips of internal port Status in neutron: Fix Released Bug description: As the title describes, if we updated fixed_ips of one internal port which associated a floatingip, but the dnat_adn_snat entry in ovn will not changed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1999209/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 2034522] Re: Fake members operating_status ONLINE
Reviewed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/893839
Committed:
https://opendev.org/openstack/ovn-octavia-provider/commit/fe6612f71475413b64e554b9a6707e35e9e5c053
Submitter: "Zuul (22348)"
Branch:master
commit fe6612f71475413b64e554b9a6707e35e9e5c053
Author: Fernando Royo
Date: Wed Sep 6 09:50:19 2023 +0200
Cover the use case of a member non existing
When a HM is attached to a pool and a backend member in that pool
is a fake member (e.g. due to a typo on creation) the member remains
in ONLINE status. Basically this is due to the fact that there
isn't any LSP attached to that member and no Service_Monitor entries
will take care of it.
This patch checks inmediatelly after creation the member and update
the whole LB status to reflect this fake member that could help to
the user to identify quickly those fake members.
Closes-Bug: 2034522
Change-Id: I72b2d9c5f454f9b156414bf91ca7deb7f0e9d8b0
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2034522
Title:
Fake members operating_status ONLINE
Status in neutron:
Fix Released
Bug description:
I can deploy members with an invalid / invented ip address (no real
servers with that address) and the LB shows that everything is ok with
them (running `openstack loadbalancer status show ` will show that
the members have "operating_status": "ONLINE".
An example: I deployed the following:
{
"loadbalancer": {
"id": "c50b7cb3-6b8f-434b-9a47-a10a27d0a9b5",
"name": "ovn_lb",
"operating_status": "ONLINE",
"provisioning_status": "ACTIVE",
"listeners": [
{
"id": "87bafdda-0ac6-438f-8824-cb75f9e014df",
"name": "tcp_listener",
"operating_status": "ONLINE",
"provisioning_status": "ACTIVE",
"pools": [
{
"id": "aa6ed64c-4d19-448b-969d-6cc686385162",
"name": "tcp_pool",
"provisioning_status": "ACTIVE",
"operating_status": "ONLINE",
"health_monitor": {
"id": "cc72e7eb-722b-49be-b3d2-3857f880346d",
"name": "hm_ovn_provider",
"type": "TCP",
"provisioning_status": "ACTIVE",
"operating_status": "ONLINE"
},
"members": [
{
"id": "648b9d51-115a-4312-b92e-cc59af0d0401",
"name": "fake_member",
"operating_status": "ONLINE",
"provisioning_status": "ACTIVE",
"address": "10.100.0.204",
"protocol_port": 80
},
{
"id": "8dae11a2-e2d5-45f9-9e85-50f61fa07753",
"name": "de3f2a06",
"operating_status": "ONLINE",
"provisioning_status": "ACTIVE",
"address": "10.0.64.34",
"protocol_port": 80
},
{
"id": "9b044180-71b4-4fa6-83df-4d0f99b4a3f7",
"name": "fake_member2",
"operating_status": "ONLINE",
"provisioning_status": "ACTIVE",
"address": "10.100.0.205",
"protocol_port": 80
},
{
"id": "fe9ce8ca-e6b7-4c5b-807c-8e295156df85",
"name": "6c186a80",
"operating_status": "ONLINE",
"provisioning_status": "ACTIVE",
"address": "10.0.64.39",
"protocol_port": 80
}
]
}
]
}
]
}
}
when the existing servers are the following:
+--+-++--+++
| ID | Name| Status | Networks
[Yahoo-eng-team] [Bug 2035332] [NEW] VLAN networks for North / South Traffic Broken
Public bug reported:
## Environment
### Deployment
- Ubuntu 22.04 LTS
- Openstack Release ZED
- Kolla-ansible - stable/zed repo
- Kolla - stable/zed repo
- Containers built with ubuntu 22.04 LTS
- Containers built on 2023-08-23
- OVN+DVR+VLAN tenant networks.
- We have three controllers occ1, occ2 occ3
- Neutron version neutron-21.1.3.dev34 commit
d6ee668cc32725cb7d15d2e08fdb50a761f91fe4
- ovn-nbctl 22.09.1
- Open vSwitch Library 3.0.3
- DB Schema 6.3.0
1. New provider network deployed into openstack, on vlan 504.
2. Router connected to this provider network.
3. Instance connected to provider network no FIP
## Issues
Attempting to send north/south traffic (ping 8.8.8.8), results in the
following symptoms. 2 pings are successful, all other pings fail, until
the ping is cancelled, and a couple of minutes pass, then two pings will
be successful again, then back to failing.
New routers with vlan networks attached don't create all three ports on
the controllers.
Even when fixing the localnet ports on the router to have three with
changing the priority when attaching a FIP the N/S traffic is limited to
2 pings
Only when setting `reside-on-redirect-chassis` to `True` can we get the
vlan to work with FIP and have baremetal nodes have FIP.
## Diagnostics
After looking at the ovn-controller logs on the control nodes we can see
that it tries to claim the port on occ0001. which matches the gateway
chassis on the routers LRP port.
```
2023-09-06T14:13:32.454Z|00718|binding|INFO|Claiming lport
cr-lrp-1a089d8f-d7a3-4116-a496-94cb87abe57f for this chassis.
2023-09-06T14:13:32.454Z|00719|binding|INFO|cr-lrp-1a089d8f-d7a3-4116-a496-94cb87abe57f:
Claiming fa:16:3e:fc:ba:cf 1xx.xx.xxx.xxx/25
```
Gateway chassis of the LRP port.
```
ovn-nbctl list Gateway_Chassis | grep -A2 -B4
lrp-71cf7286-de37-4d86-b362-eb7ba689d2d1
_uuid : cf26be06-206d-443c-b224-25cc06ef2094
chassis_name: occ2
external_ids: {}
name: lrp-71cf7286-de37-4d86-b362-eb7ba689d2d1_occ2
options : {}
priority: 2
--
_uuid : 1d9e8314-ed00-4694-8974-0328b78d34e1
chassis_name: occ1
external_ids: {}
name: lrp-71cf7286-de37-4d86-b362-eb7ba689d2d1_occ1
options : {}
priority: 3
--
_uuid : b1e41ceb-ca2d-42eb-a896-b3551ea1b32f
chassis_name: occ3
external_ids: {}
name: lrp-71cf7286-de37-4d86-b362-eb7ba689d2d1_occ3
options : {}
priority: 1
```
We see nothing about `occ2` or `occ3` trying to claim the LRP port but
we found that when you change the priority around to try resolve, we can see
that the port is not on `occ1` but is on occ0002
We change occ0001 = 1 and occ0003 = 3 which means `occ3` will be come the
highest gateway.
```
ovn-nbctl set gateway_chassis 1d9e8314-ed00-4694-8974-0328b78d34e1 priority=1
ovn-nbctl set gateway_chassis b1e41ceb-ca2d-42eb-a896-b3551ea1b32f priority=3
```
the logs show the following.
occ0001
```
2023-09-06T14:10:06.134Z|00667|binding|INFO|Releasing lport
cr-lrp-71cf7286-de37-4d86-b362-eb7ba689d2d1 from this chassis (sb_readonly=0)
2023-09-06T14:10:06.134Z|00668|if_status|WARN|Trying to release unknown
interface cr-lrp-71cf7286-de37-4d86-b362-eb7ba689d2d1
```
occ0002
```
2023-09-06T14:10:14.883Z|00444|binding|INFO|Releasing lport
cr-lrp-71cf7286-de37-4d86-b362-eb7ba689d2d1 from this chassis (sb_readonly=0)
2023-09-06T14:10:14.883Z|00445|if_status|WARN|Trying to release unknown
interface cr-lrp-71cf7286-de37-4d86-b362-eb7ba689d2d1
```
occ0003
```
2023-09-06T14:10:14.789Z|00459|binding|INFO|Changing chassis for lport
cr-lrp-71cf7286-de37-4d86-b362-eb7ba689d2d1 from occ2 to occ3.
2023-09-06T14:10:14.789Z|00460|binding|INFO|cr-lrp-71cf7286-de37-4d86-b362-eb7ba689d2d1:
Claiming fa:16:3e:71:df:71 1xx.xx.xxx.xxx/25
```
on `occ3` we can see that `occ2` had the gateway and not
`occ1` which it should of had. This happens on creating new routers
on the vlan provider network.All exisiting Routers before upgrade are
working and that they have the same priority.
## Second diagnostics
Looking at each Logical Router we can see that when the router is first created
that only two of the three ports are created.
Broken router:
```
_uuid : 773bb527-f193-4b47-8685-e62c9325dd7b
copp: []
enabled : true
external_ids: {"neutron:availability_zone_hints"="",
"neutron:gw_network_id"="c9d130bc-301d-45c0-9328-a6964af65579",
"neutron:gw_port_id"="1a089d8f-d7a3-4116-a496-94cb87abe57f",
"neutron:revision_number"="4", "neutron:router_name"=new-r1-test}
load_balancer : []
load_balancer_group : []
name: neutron-2b51e12e-5505-477e-9720-e5db31a05790
nat : [f22e6004-ad69-4b12-9445-7006a03495f5]
options : {always_learn_from_arp_request="false",
[Yahoo-eng-team] [Bug 2035325] [NEW] FDB entries grows indefinitely
Public bug reported: With the added support for learning FDB entries [1] there is a problem that FDB table can grow indefinitely, leading to performance/scale issues. New options are added to OVN [2] to tackle this problem, and neutron should make use of it [1] https://review.opendev.org/c/openstack/neutron/+/877675 [2] https://github.com/ovn-org/ovn/commit/ae9a5488824c49e25215b02e7e81a62eb4d0bd53 ** Affects: neutron Importance: Undecided Assignee: Luis Tomas (luis5tb) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Luis Tomas (luis5tb) ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2035325 Title: FDB entries grows indefinitely Status in neutron: In Progress Bug description: With the added support for learning FDB entries [1] there is a problem that FDB table can grow indefinitely, leading to performance/scale issues. New options are added to OVN [2] to tackle this problem, and neutron should make use of it [1] https://review.opendev.org/c/openstack/neutron/+/877675 [2] https://github.com/ovn-org/ovn/commit/ae9a5488824c49e25215b02e7e81a62eb4d0bd53 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2035325/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1983863] Re: Can't log within tpool.execute
** Changed in: nova Status: In Progress => Invalid ** Changed in: nova Status: Invalid => Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1983863 Title: Can't log within tpool.execute Status in OpenStack Compute (nova): Fix Committed Status in oslo.log: Fix Released Bug description: There is a bug in eventlet where logging within a native thread can lead to a deadlock situation: https://github.com/eventlet/eventlet/issues/432 When encountered with this issue some projects in OpenStack using oslo.log, eg. Cinder, resolve them by removing any logging withing native threads. There is actually a better approach. The Swift team came up with a solution a long time ago, and it would be great if oslo.log could use this workaround automaticaly: https://opendev.org/openstack/swift/commit/69c715c505cf9e5df29dc1dff2fa1a4847471cb6 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1983863/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
