opendevreview | liuyulong proposed openstack/neutron master: Always get local vlan from port other_config https://review.opendev.org/c/openstack/neutron/+/923040 | 03:45 |
---|---|---|
*** liuxie is now known as liushy | 05:43 | |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add the port "fixed_ips" information in the DHCP RPC https://review.opendev.org/c/openstack/neutron/+/923026 | 05:55 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == Reduce the DHCP processing loop to a single thread https://review.opendev.org/c/openstack/neutron/+/922719 | 05:55 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Use the RBAC actions field for "network" and "subnet" https://review.opendev.org/c/openstack/neutron/+/915370 | 05:58 |
opendevreview | Bence Romsics proposed openstack/os-vif master: Do not add taps in trunk bridges to the dead vlan https://review.opendev.org/c/openstack/os-vif/+/923036 | 11:46 |
opendevreview | Bence Romsics proposed openstack/neutron master: Put trunk tpi/spi ports in the dead vlan https://review.opendev.org/c/openstack/neutron/+/923035 | 11:49 |
racosta | hey haleyb, ralonsoh, I tried to simulate the performance issue of big queries caused by joined in the qos tables but I didn't see a big query occur at any time. | 13:42 |
racosta | However, what I saw was a series of selects for qospolicyrbacs table within a select count(*). | 13:42 |
racosta | https://paste.openstack.org/show/bLYLjStgHlwY5S38f8NG/ | 13:43 |
ralonsoh | racosta, and do you know why this is needed? when this is called? | 13:48 |
ralonsoh | in any case, I'm investigating the LP#2071374 right now | 13:48 |
racosta | this is called in the command "openstack network qos policy list" | 13:48 |
ralonsoh | yeah but when, in the code, is this called? | 13:49 |
ralonsoh | and is this also called for other resources? | 13:49 |
racosta | good question, I don't know where specifically it is called. | 13:50 |
racosta | for qos rule commands I didn't see the problem because I need to pass the policy as a filter | 13:51 |
ralonsoh | btw, I'll comment on the bug: this bug is related to https://bugs.launchpad.net/neutron/+bug/2037107 | 13:51 |
ralonsoh | the problem of the subnet RBACs is that the RBACs are not child registers of the resource (subnet) but of the parent resource (network) | 13:52 |
ralonsoh | that creates a SQL query that cannot be optimized and returns this amount of results (low cardinality) | 13:53 |
ralonsoh | so my proposal, and I'm going to try that, is to have a specific hook for the "subnet list" query command, retrieving first the network IDs form the subnets | 13:53 |
racosta | sure, this isn't the same case of qos policy. | 13:54 |
ralonsoh | (filtering using the provided RBACs) and then retrieve the networks subnets | 13:54 |
ralonsoh | no, qos policies (same as any other resource), have explicit RBAC child registers | 13:54 |
ralonsoh | but not the subnets | 13:54 |
racosta | yeap | 13:55 |
racosta | I was only able to simulate a big query in the LP#2071374. | 13:56 |
racosta | Changing the rbac loader inside subnetpool solves the problem, splitting into smaller queries with selectin and keepingthe relationship by exactly the number os rbacs within the subnet table. | 14:02 |
ralonsoh | racosta, how do I reproduce the subnetpool issue? | 14:16 |
ralonsoh | because I can't see this problem even with several projects and subnetpools | 14:16 |
racosta | you need to create one or more subnet pools and then associate it with a project via rbac. | 14:18 |
racosta | creating a subnet with this pool (which was created in another project: openstack admin, for example.) | 14:19 |
racosta | I put some topology information in the bug. | 14:21 |
racosta | at the end of the day the problem is that a "network list" creates a series of left outer joins for subnets and subnetpools with rbacs. | 14:22 |
ralonsoh | but why a subnet must be created? | 14:22 |
ralonsoh | when retrieving the subpool we don't retrieve the subnets | 14:22 |
racosta | I don't know if I understand your point. When we create a service project via OpenStack, these projects will have subnets derived from a single subnetpool. | 14:25 |
ralonsoh | yes, and when you do "openstack subnet pool list", there is no time issue | 14:26 |
ralonsoh | it doesn't matter if you create the subnets with or without a subnetpool | 14:27 |
racosta | Exactly, the problem is not with the subnetpool itself but in the relationship that the subnet table makes with it when we're using rbacs. | 14:30 |
racosta | The ORM model can be tricky sometimes, I placed the query that it assembles, the end result is more than 500k entries. | 14:31 |
racosta | After creating the related resources, to reproduce the issue just run a "network list" command. | 14:35 |
ralonsoh | no, with network list I don't have this issue | 14:38 |
ralonsoh | I've created 500 projects, 500 networks and 500 subnets | 14:39 |
ralonsoh | and I've shared 1 network per project | 14:39 |
ralonsoh | the API time to retrieve the networks is 0.57 seconds | 14:39 |
ralonsoh | for the subnets is 5.44 seconds | 14:39 |
ralonsoh | so this bug is actually https://bugs.launchpad.net/neutron/+bug/2037107 | 14:40 |
racosta | Ok, but did you create address scope and subnet pool to use in project subnets as I reported in the bug? | 14:50 |
ralonsoh | yes I did | 14:51 |
racosta | well, maybe we are missing something because the list of networks should be taking similar time as the list of subnets (at least that's what I see on my side). | 14:56 |
opendevreview | Merged openstack/neutron master: Fix ML2/OVN OVSDB handling of gateway ports https://review.opendev.org/c/openstack/neutron/+/918151 | 17:14 |
opendevreview | Merged openstack/neutron master: Add the port "fixed_ips" information in the DHCP RPC https://review.opendev.org/c/openstack/neutron/+/923026 | 17:14 |
opendevreview | Brian Haley proposed openstack/neutron master: Change OVN client to account for nested networks https://review.opendev.org/c/openstack/neutron/+/907504 | 18:41 |
opendevreview | Miro Tomaska proposed openstack/neutron stable/2023.1: [2023.1 Only][OVN] Add the bridge name and datapath type to the port VIF details https://review.opendev.org/c/openstack/neutron/+/922431 | 19:39 |
opendevreview | Terry Wilson proposed openstack/neutron stable/2024.1: Use oslo_service's SignalHandler for signals https://review.opendev.org/c/openstack/neutron/+/923187 | 20:59 |
opendevreview | Terry Wilson proposed openstack/neutron stable/2024.1: Use oslo_service's SignalHandler for signals https://review.opendev.org/c/openstack/neutron/+/923187 | 21:03 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!