| *** yoctozepto8 is now known as yoctozepto | 00:33 | |
| opendevreview | Merged openstack/neutron-lib master: Do not use deprecated attributes of RequestContext https://review.opendev.org/c/openstack/neutron-lib/+/805488 | 00:53 |
|---|---|---|
| *** yoctozepto6 is now known as yoctozepto | 01:21 | |
| *** yoctozepto3 is now known as yoctozepto | 02:12 | |
| *** yoctozepto8 is now known as yoctozepto | 03:43 | |
| *** yoctozepto8 is now known as yoctozepto | 03:57 | |
| *** yoctozepto0 is now known as yoctozepto | 04:12 | |
| *** yoctozepto1 is now known as yoctozepto | 04:40 | |
| *** yoctozepto7 is now known as yoctozepto | 05:43 | |
| opendevreview | Oleg Bondarev proposed openstack/neutron-lib master: Add Local IP API def https://review.opendev.org/c/openstack/neutron-lib/+/803051 | 06:15 |
| *** yoctozepto0 is now known as yoctozepto | 06:24 | |
| *** redrobot0 is now known as redrobot | 06:29 | |
| *** yoctozepto9 is now known as yoctozepto | 07:00 | |
| opendevreview | Shawn.Lu proposed openstack/neutron stable/wallaby: Do not call delete segement when segment plugin disabled https://review.opendev.org/c/openstack/neutron/+/805788 | 07:25 |
| *** rpittau|afk is now known as rpittau | 07:27 | |
| opendevreview | Przemyslaw Szczerbik proposed openstack/neutron master: Fix gate for neutron-lib v2.14 https://review.opendev.org/c/openstack/neutron/+/805627 | 07:31 |
| *** yoctozepto1 is now known as yoctozepto | 07:52 | |
| opendevreview | Javier Peña proposed openstack/neutron stable/wallaby: Replace assertItemsEqual with assertCountEqual https://review.opendev.org/c/openstack/neutron/+/805791 | 08:06 |
| opendevreview | Javier Peña proposed openstack/neutron stable/wallaby: Follow up for replacing assertItemsEqual https://review.opendev.org/c/openstack/neutron/+/805792 | 08:06 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVS][FW] Initialize ConjIdMap._max_id depending on the current OFs https://review.opendev.org/c/openstack/neutron/+/804236 | 08:13 |
| opendevreview | Przemyslaw Szczerbik proposed openstack/neutron master: Fix gate for neutron-lib v2.14 https://review.opendev.org/c/openstack/neutron/+/805627 | 08:39 |
| slaweq | jlibosva: hi, did You maybe had any chance to look again at https://bugs.launchpad.net/neutron/+bug/1938766 ? | 08:53 |
| * jlibosva looks | 08:53 | |
| slaweq | amotoki added some comment to that bug recently | 08:53 |
| slaweq | and this is most common issue in functional tests job now :/ | 08:53 |
| lajoskatona | last week it was easy to reproduce locally, but I had no idea other than random tries | 08:56 |
| jlibosva | slaweq: would it be a solution to fallback to older OVS? | 08:58 |
| opendevreview | Przemyslaw Szczerbik proposed openstack/neutron master: Bump os-resource-classes lib to 1.1.0 https://review.opendev.org/c/openstack/neutron/+/801066 | 09:01 |
| slaweq | jlibosva: we can try I think but that's short term workaround, right? | 09:03 |
| jlibosva | slaweq: yes, I think the fix should go to OVS | 09:03 |
| slaweq | jlibosva: do You know if that issue is reported for OVS somewhere? | 09:04 |
| slaweq | so we can add note about it in job's definition | 09:04 |
| jlibosva | slaweq: yes, it's reported in RH BZ and the team is working on it | 09:04 |
| slaweq | jlibosva great, so can You propose patch or do You want me to do it? | 09:04 |
| jlibosva | slaweq: I can try to reproduce locally and figure out what version we need. The patch I found was quite old and doesn't correlate with the time we started to see the issue | 09:05 |
| slaweq | jlibosva: ok, thx a lot | 09:05 |
| opendevreview | Eduardo Olivares proposed openstack/neutron-tempest-plugin master: Checking IP version from extra-dhcp-options https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/804755 | 09:07 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/wallaby: Replace assertItemsEqual with assertCountEqual https://review.opendev.org/c/openstack/neutron/+/805791 | 10:01 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-specs master: Create intermediate OVS bridge to improve live-migration in OVN https://review.opendev.org/c/openstack/neutron-specs/+/799198 | 10:07 |
| opendevreview | Mark Goddard proposed openstack/neutron stable/wallaby: Add wait for the post-fork event to nb/sb objects https://review.opendev.org/c/openstack/neutron/+/805768 | 10:13 |
| opendevreview | Mark Goddard proposed openstack/neutron stable/wallaby: Add wait for the post-fork event to nb/sb objects https://review.opendev.org/c/openstack/neutron/+/805768 | 10:14 |
| opendevreview | Mark Goddard proposed openstack/neutron stable/victoria: Add wait for the post-fork event to nb/sb objects https://review.opendev.org/c/openstack/neutron/+/805769 | 10:18 |
| JohnnyW | Hi is there a way to speed up routers to propagate on neutron, after restart of neutron-l3-agent? I see that first routers propagate quickly, but after 50-60 routers it is really slowing down(and I have around 250 routers to migrate). I couldn't find anything in logs, so I'm not sure what is a reason here. Any advice what can be checked or? Thanks | 10:23 |
| JohnnyW | in advance! | 10:23 |
| kklimonda | hmm, with ussuri ml2/ovn it seems wsgi workers are responsible for processing updates sent by ovsdb servers? | 11:04 |
| kklimonda | I'm seeing a problem where the amount of changes in southbound db (chassis_private) seems to be blocking wsgi workers and affect api | 11:04 |
| ralonsoh | kklimonda, wsgi server (neutron API) creates an IDL connection to OVN SB and NB. So yes, the neutron API process all OVN updates (as there are not Openstack compute agents) | 11:05 |
| ralonsoh | what is happening? | 11:06 |
| kklimonda | I'm probably not running enough api_workers due to it being a virtualized environment that ran out of cpu, but I'm curious if there is a scaling issue here - does hash ring implementation split ovn updates between api workers? | 11:06 |
| kklimonda | I have 250 chassis in this deployment | 11:07 |
| ralonsoh | yes, all requests are attended by a single API worker | 11:07 |
| ralonsoh | in parallel | 11:07 |
| ralonsoh | what operation is blocking the neutron server? | 11:07 |
| ralonsoh | there should not be so many changes in chassis_private | 11:08 |
| kklimonda | why, every change to northbound db turns into 250 updates to chassis_private | 11:10 |
| ralonsoh | how | 11:11 |
| kklimonda | give me a sec | 11:11 |
| kklimonda | sorry, just got a quick call to end | 11:11 |
| kklimonda | when neutron makes change to northbound db it updates nb_cfg field | 11:12 |
| kklimonda | ovn-controller then updates chassis_private setting nb_cfg there | 11:14 |
| kklimonda | and this turns into an update that has to be processed by neutron - that's probably because I'm running with https://review.opendev.org/c/openstack/neutron/+/752795/ backpored | 11:14 |
| ralonsoh | nb_cfg is updated when the chassis is updated. If a change in NB implies a change in a chassis, that will be needee | 11:19 |
| ralonsoh | what I don't understand is that the NB changes implies 250 updates in nb_cfg field | 11:19 |
| ralonsoh | if you have an example, that could be useful | 11:19 |
| opendevreview | Przemyslaw Szczerbik proposed openstack/neutron master: Fix gate for neutron-lib v2.14 https://review.opendev.org/c/openstack/neutron/+/805627 | 11:25 |
| ralonsoh | ^^^ folks, we need this n-lib patch | 11:28 |
| obondarev | ralonsoh: can you please re-post the link again? Just connected | 11:30 |
| ralonsoh | obondarev, https://review.opendev.org/c/openstack/neutron/+/805627 | 11:30 |
| obondarev | thanks | 11:31 |
| kklimonda | ralonsoh: ok, so this is how I understand this: | 11:32 |
| kklimonda | ralonsoh: when neutron makes a change to ovn it increments nb_cfg field in NB_Global | 11:33 |
| ralonsoh | same as in sb.SB_Global.sb_cfg | 11:35 |
| ralonsoh | but this is not the chassis_private.nb_cfg | 11:36 |
| kklimonda | ralonsoh: this change is processed via ovn-northd into SB_Global.nb_cfg | 11:37 |
| ralonsoh | yes, but this is not chassis_private.nb_cfg | 11:38 |
| ralonsoh | I don't think we have an event for SB_Global | 11:38 |
| ralonsoh | let me check | 11:38 |
| kklimonda | ovn-controller then updates it's entry in Chassis_Private setting nb_cfg columnt | 11:38 |
| ralonsoh | yes, the corresponding one | 11:39 |
| kklimonda | this is with https://review.opendev.org/c/openstack/neutron/+/752795/ applied that changes how agent liveness is handled | 11:39 |
| ralonsoh | hmmm in https://review.opendev.org/c/openstack/neutron/+/752795/29/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovsdb_monitor.py we capture any SB_Global event | 11:40 |
| ralonsoh | then we filter, but that implies we first attend to the change in SB_Global | 11:40 |
| ralonsoh | yeah, that could be too much | 11:40 |
| ralonsoh | are you going to open a LP bug? | 11:41 |
| kklimonda | sure | 11:41 |
| ralonsoh | thanks a lot | 11:41 |
| ralonsoh | kklimonda, please, refer to patch https://review.opendev.org/c/openstack/neutron/+/752795/29/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovsdb_monitor.py#249 | 11:41 |
| ralonsoh | and this file | 11:41 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/wallaby: Follow up for replacing assertItemsEqual https://review.opendev.org/c/openstack/neutron/+/805792 | 12:02 |
| opendevreview | Lajos Katona proposed openstack/neutron-lib master: Fix hostroute validation with BFD https://review.opendev.org/c/openstack/neutron-lib/+/805834 | 12:03 |
| kklimonda | ralonsoh: https://bugs.launchpad.net/neutron/+bug/1940950 | 12:09 |
| opendevreview | Merged openstack/neutron-lib master: Add network_ip_availability pagging and sorting support https://review.opendev.org/c/openstack/neutron-lib/+/803050 | 12:39 |
| opendevreview | Oleg Bondarev proposed openstack/neutron master: [WIP] Add Local IP Extension and DB https://review.opendev.org/c/openstack/neutron/+/804523 | 13:00 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Do not fail when releasing a quota reservation https://review.opendev.org/c/openstack/neutron/+/805031 | 13:03 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Replace "tenant_id" with "project_id" in Quota engine https://review.opendev.org/c/openstack/neutron/+/805849 | 13:25 |
| slaweq | #startmeeting networking | 14:00 |
| opendevmeet | Meeting started Tue Aug 24 14:00:04 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'networking' | 14:00 |
| mlavalle | o/ | 14:00 |
| ralonsoh | hi | 14:00 |
| slaweq | hi | 14:00 |
| ganso | hi | 14:00 |
| lajoskatona | Hi | 14:00 |
| bcafarel | o/ | 14:00 |
| obondarev | hi | 14:01 |
| amotoki | o/ | 14:01 |
| slaweq | let's wait 2 more minutes for others | 14:01 |
| slaweq | and we will start | 14:01 |
| slaweq | ok, let's go | 14:02 |
| slaweq | #topic Announcements | 14:02 |
| slaweq | first of all Xena cycle calendar https://releases.openstack.org/xena/schedule.html | 14:02 |
| slaweq | last week we released final releases for non-client libraries | 14:02 |
| slaweq | but I think I made some mistake when I was checking calendar | 14:03 |
| thomasb06 | hi | 14:03 |
| manubk | hi | 14:03 |
| slaweq | and deadline for non-client libs is this week really :) | 14:03 |
| slaweq | I really don't know how I made that mistake | 14:04 |
| lajoskatona | there was a mail about it: http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024291.html | 14:04 |
| lajoskatona | so it was an openstack global miscommunication :-) | 14:04 |
| slaweq | lajoskatona thx | 14:04 |
| slaweq | I missed that email as on Friday I was off | 14:04 |
| slaweq | so it's not that bad with me at least :) | 14:04 |
| mlavalle | lol | 14:05 |
| slaweq | so, if You have any last minute think which You would like to include in Xena e.g. in neutron-lib, please ping me - we can make another release if needed | 14:05 |
| slaweq | otherwise we are good with those libs already :) | 14:05 |
| slaweq | it's better to made mistake that way than in the other one :D | 14:06 |
| lajoskatona | +1 | 14:06 |
| slaweq | next week we will have Xena-3 milestone and final release for client libraries | 14:07 |
| slaweq | so we will need to cut python-neutronclient but I don't think there is anything urgent waiting for review there | 14:07 |
| slaweq | if there is something important for You, please ping me about it on irc or by email | 14:07 |
| slaweq | ok, moving on to the next announcement | 14:08 |
| slaweq | TC & PTL Nominations ends today: https://governance.openstack.org/election/ | 14:08 |
| slaweq | we have great candidate already - thx lajoskatona for stepping in :) | 14:08 |
| ralonsoh | +1 | 14:09 |
| mlavalle | +1 | 14:09 |
| obondarev | +1 | 14:09 |
| slaweq | so it's probably that next week we will have new PTL already :) | 14:09 |
| lajoskatona | hope that can't destroy years work in half a year.... | 14:09 |
| ralonsoh | I'll help you to do it (to destroy, I mean) | 14:09 |
| slaweq | lajoskatona I'm sure You will do great :) | 14:09 |
| slaweq | ralonsoh: LOL | 14:10 |
| bcafarel | I'm not worried either :) | 14:10 |
| obondarev | lajoskatona: didn't see that in your goals! :D | 14:10 |
| amotoki | let's break our bad things and improve them :) | 14:10 |
| lajoskatona | +1 | 14:11 |
| slaweq | next one | 14:11 |
| slaweq | October PTG | 14:12 |
| slaweq | etherpad https://etherpad.opendev.org/p/neutron-yoga-ptg | 14:12 |
| slaweq | Please add Your topics there | 14:12 |
| slaweq | Operator pain points etherpad https://etherpad.opendev.org/p/pain-point-elimination | 14:12 |
| slaweq | please add Yours if You have any | 14:12 |
| slaweq | and that's are all announcements/reminders which I had for You | 14:13 |
| slaweq | anything else You want to add in that section? | 14:13 |
| slaweq | if not, let's move on to the next topic | 14:15 |
| slaweq | #topic Blueprints | 14:15 |
| slaweq | for Xena-3 we still have those BPs https://bugs.launchpad.net/neutron/+milestone/xena-3 | 14:15 |
| slaweq | I don't think we will be able to complete any of them in this cycle really | 14:15 |
| slaweq | for BGP related stuff I updated status to "good progress" today as all of them have at least api-ref merged already | 14:16 |
| slaweq | but there's no neutron implementation for any of them now | 14:16 |
| slaweq | next week I will probably move them to neutron-next | 14:16 |
| slaweq | as I don't think we need to schedule any of them for the Xena RC milestone | 14:16 |
| slaweq | are You ok with that? | 14:17 |
| lajoskatona | for me ok | 14:18 |
| ralonsoh | +1 | 14:18 |
| mlavalle | +1 | 14:19 |
| slaweq | thx | 14:19 |
| slaweq | so, I think we can move on | 14:20 |
| slaweq | to the next topic | 14:20 |
| slaweq | #topic Bugs | 14:20 |
| slaweq | I was bug deputy last week. Report http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024308.html | 14:20 |
| slaweq | there is couple of bugs which I wanted to raise today | 14:20 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1940071 - that is vpnaas issue | 14:20 |
| slaweq | seems like some memory leak in vpnaas | 14:21 |
| slaweq | maybe someone who is more familiar with vpnaas could take a look | 14:21 |
| ralonsoh | I wish this could help: https://review.opendev.org/c/openstack/neutron/+/803034 | 14:22 |
| slaweq | ralonsoh yes, hopefully it will :) | 14:22 |
| slaweq | next one | 14:23 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1940425 - that is gate failure, not very often but I think it's worth to take a look | 14:24 |
| ralonsoh | could be related to a bug we have in RH | 14:25 |
| ralonsoh | this is related to the RPC timeout | 14:25 |
| ralonsoh | I'll check the logs | 14:25 |
| slaweq | ralonsoh thx | 14:25 |
| ralonsoh | (in a nutshell, the parent port activation waits until all subports are bound) | 14:25 |
| slaweq | next we have 2 low-hanging-fruits (IMO): | 14:26 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1940074 | 14:26 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1940073 | 14:26 |
| slaweq | for https://bugs.launchpad.net/neutron/+bug/1940074 there is actually patch already | 14:26 |
| slaweq | so only https://bugs.launchpad.net/neutron/+bug/1940073 is still free to take :) | 14:27 |
| slaweq | and the last one: https://bugs.launchpad.net/neutron/+bug/1940086 - that is api-ref thing | 14:27 |
| slaweq | maybe someone wants to propose update there | 14:28 |
| slaweq | all other bugs from last week are already assigned to someone | 14:28 |
| slaweq | any other bugs You want to discuss today? | 14:29 |
| slaweq | ok, I guess that this means "no" | 14:30 |
| slaweq | this week bug deputy is hongbin | 14:31 |
| slaweq | and I already asked him last week about it | 14:31 |
| slaweq | he confirmed me that he will do it | 14:31 |
| slaweq | next week will be haleyb | 14:32 |
| slaweq | I will ask him if he will be able to do it | 14:32 |
| slaweq | and that's basically all what I have for today | 14:32 |
| slaweq | #topic On Demand Agenda | 14:32 |
| slaweq | do You have any other topics to discuss today? | 14:33 |
| ganso | I do | 14:33 |
| ganso | sorry I updated the agenda after the meeting had started | 14:33 |
| slaweq | ganso go on then :) | 14:33 |
| ganso | thanks | 14:33 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Replace "tenant_id" with "project_id" in Quota engine https://review.opendev.org/c/openstack/neutron/+/805849 | 14:33 |
| ganso | I'm interested in implementing pagination across some pages in horizon, main network list | 14:34 |
| ganso | but also routers, SGs, FIPs | 14:34 |
| ganso | one thing that drew my attention about network list is that the horizon network list is different than the CLI list | 14:34 |
| ganso | because of this: https://github.com/openstack/horizon/blob/1800750804502adf9ff31366daa987aeb9acba31/openstack_dashboard/api/neutron.py#L1075 | 14:34 |
| ganso | basically CLI list lists everything, even across tenants, if the user has those privileges | 14:35 |
| ganso | the horizon one doesn't, it filters by tenants, and by doing that it causes 2 things | 14:35 |
| ganso | 1) the initial query filters out shared and external (especially when those are not created by the tenant listing the networks) | 14:35 |
| ganso | 2) It makes it very complicated ( impossible perhaps) to paginate this consistently, because what it does today it performs other separate queries to integrate the shared and external networks in the list | 14:36 |
| ganso | since we don't know how many external / shared ones there are beforehand, we would need to do very hacky things to paginate | 14:37 |
| ganso | so, I would like to ask: why do we need horizon to be different than the CLI? can't we make them behave similarly and get rid of this tenant filter? | 14:37 |
| amotoki | it is due to the nature of horizon "project" panel. The project panel focuses on operations owned by a target tenant. | 14:38 |
| amotoki | "admin" users can list all networks (or resources) from all projects. It is confuisng as the "project" panel. | 14:38 |
| amotoki | this is the reason I added such hacky thing you explained. | 14:38 |
| slaweq | personally from Neutron pov I don't see any reason why it shouldn't be the same | 14:38 |
| slaweq | it's more question to the Horizon team IMO | 14:39 |
| slaweq | so amotoki is the best one to answer :) | 14:39 |
| ganso | amotoki: looking at the other side of this, the neutron CLI is the only one that does this, when compared to nova and cinder. The Horizon way of doing is actually more consistent with how nova and cinder do | 14:39 |
| ganso | nova and cinder's CLI does not list resources of other tenants, despite the user being admin, unless you specify "--all-projects" | 14:40 |
| amotoki | "CLI" can be reworeed with "API" as neturon CLI does not filter anything. | 14:40 |
| amotoki | compared to the nova/cinder API, the neutron API behavior differently. | 14:40 |
| ganso | yes | 14:40 |
| amotoki | in case of nova/clnder, even though an API consumer has "admin"-ness, nova/cinder API returns resources owned by a target project. | 14:41 |
| amotoki | this is the different point from neutron. | 14:41 |
| ganso | I see the neutron API behavior as the official and desired one by its community, so I wouldn't say we would have to change how the API behaves. Horizon on the other hand, could do the same as the API instead of doing something different | 14:41 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron-tempest-plugin master: Check if advanced image flavor already exists https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/805864 | 14:42 |
| amotoki | when nova/cinder/neutron API were designed there was no consensus on how API should work when called with "admin"-ness. this leads to different behaviors between nova/cinder and neutron APIs. | 14:42 |
| ganso | so, how do we move forward from here? I understand Horizon's premise of being different, but do we all agree with this? is this better than not having pagination? My main motivation is because customers are having timeouts listing networks while loading the network list page | 14:43 |
| amotoki | horizon implementation is just to handle these differences. Basically horizon "project" panel behavior assumes nova/cinder API behaviors and the logic for neutron APi is to handle it. | 14:43 |
| amotoki | ganso: I don't have a clear answer right now. | 14:44 |
| amotoki | at least changing the existing API behaviors in nova/cinder/neutron is really confusing. | 14:45 |
| obondarev | can we add a parameter to API, that horizon can use to get similar to nova/cinder bahavior? | 14:46 |
| slaweq | just an idea: maybe we could add some flag in neutron API, something like "include_shared" so user could do call like "network list --tenant-id <tenant> --include-shared True" to get all shared and own networks in one request | 14:46 |
| amotoki | it is one possible idea but on the other hand it is not a good thing to change the API behavior beased on configurations. | 14:47 |
| obondarev | not config | 14:47 |
| amotoki | ah, I misunderstood. | 14:47 |
| slaweq | it's API parameter | 14:47 |
| slaweq | not config | 14:47 |
| amotoki | it is about "API parameter" | 14:47 |
| slaweq | so horizon could use it | 14:48 |
| ganso | alternatively add a "--all-projects" that default to True (defaulting to True is weird, but trying to maintain the same behavior) | 14:48 |
| ganso | then horizon would say "--all-projects" false | 14:48 |
| slaweq | that's also some possibility | 14:49 |
| slaweq | for sure we will need RFE for that | 14:49 |
| slaweq | and we will need to discuss it carefully in drivers meeting :) | 14:50 |
| slaweq | ganso would that be ok to propose such RFE for Neutron? | 14:50 |
| slaweq | amotoki and would it be ok for You to work with ganso on that RFE? You are the best guy in our team to help with that :) | 14:51 |
| amotoki | slaweq: yes | 14:51 |
| ganso | Let me ask something on the other extreme first, as I assume we would all like to avoid making API changes for this. If I am able to implement something hacky that accomplishes pagination despite being inefficient, would that be acceptable? | 14:51 |
| slaweq | in Neutron or Horizon You mean? | 14:52 |
| ganso | Horizon | 14:52 |
| ganso | only touching Horizon | 14:52 |
| slaweq | that's question to Horizon team I guess :) | 14:52 |
| amotoki | horizon is also studying the support of system-scope and the situation may change as API reuqests with a regular user no longer have admin-ness (after switching to system-scope token) | 14:53 |
| ganso | oh ok. And the question of if that would be backportable (given that pagination is perhaps a new feature, but addressing the lack of pagination as being a bug), is also up to Horizon team? | 14:53 |
| slaweq | ganso all changes in Horizon are up to Horizon team | 14:54 |
| ganso | ok | 14:54 |
| slaweq | from us here only amotoki is part of Horizon team also | 14:54 |
| amotoki | ganso: yes. it is up to horizon team but generally speaking it depends on how big the change is. the stable policy is not break a released deliverable. | 14:54 |
| ganso | I will spend some more time on that and see what I can come up with, now knowing that the alternative route is through adding parameters to Neutron API | 14:54 |
| slaweq | ganso that's some possiblitity which we may explore more for sure | 14:55 |
| amotoki | ganso: thanks for raising this. I am glad to help | 14:55 |
| ganso | ok, thanks! that's all I had, I will keep in touch with amotoki and slaweq. =) | 14:56 |
| slaweq | thx ganso | 14:56 |
| slaweq | any other last minute topics? | 14:56 |
| amotoki | for long term, it may be a good thing to achieve consistency between nova/cinder/neutron APi behaviors. | 14:57 |
| amotoki | it would not happen in short term, but it is worth considering it as long term | 14:57 |
| amotoki | no more from me :p | 14:57 |
| slaweq | amotoki thx a lot | 14:57 |
| slaweq | so I think we are good to go today | 14:58 |
| slaweq | thx for attending the meeting and see You next week (hopefully with our new great PTL already :)) | 14:58 |
| slaweq | o/ | 14:58 |
| slaweq | #endmeeting | 14:58 |
| opendevmeet | Meeting ended Tue Aug 24 14:58:39 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:58 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/networking/2021/networking.2021-08-24-14.00.html | 14:58 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/networking/2021/networking.2021-08-24-14.00.txt | 14:58 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/networking/2021/networking.2021-08-24-14.00.log.html | 14:58 |
| mlavalle | o/ | 14:58 |
| amotoki | o/ | 14:58 |
| ralonsoh | bye | 14:58 |
| thomasb06 | bye | 14:58 |
| lajoskatona | bye | 14:59 |
| slaweq | #startmeeting neutron_ci | 15:00 |
| opendevmeet | Meeting started Tue Aug 24 15:00:06 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'neutron_ci' | 15:00 |
| slaweq | hi (again) :) | 15:00 |
| obondarev | hi | 15:00 |
| ralonsoh | hi | 15:00 |
| slaweq | Grafana dashboard: http://grafana.openstack.org/dashboard/db/neutron-failure-rate | 15:00 |
| bcafarel | that was a short break :) | 15:00 |
| thomasb06 | hi | 15:00 |
| lajoskatona | Hi | 15:00 |
| slaweq | let's do it quick as ralonsoh needs to leave early today :) | 15:01 |
| slaweq | #topic Actions from previous meetings | 15:01 |
| slaweq | obondarev to update grafana after promoting dvr-ha job to be voting | 15:01 |
| obondarev | https://review.opendev.org/c/openstack/project-config/+/805594 | 15:01 |
| obondarev | not sure if it's all needed however | 15:01 |
| obondarev | I mean that I might missed something | 15:02 |
| slaweq | thx obondarev | 15:02 |
| slaweq | I think it's ok | 15:02 |
| bcafarel | for graph itself probably not, but it is nice to have proper labels :) | 15:02 |
| slaweq | next one | 15:03 |
| slaweq | ralonsoh to send patches to use smaller flavors and concurency 1 for advanced scenario tests | 15:03 |
| ralonsoh | and bcafarel | 15:03 |
| ralonsoh | https://review.opendev.org/q/79c679683dd93c1df412f81533af6bf72e2395d0 | 15:03 |
| ralonsoh | first one is merged | 15:03 |
| ralonsoh | please check bcafarel's one | 15:03 |
| ralonsoh | I think with this patch we can close the bug (for now) | 15:03 |
| ralonsoh | the concurrency patch won't be needed | 15:04 |
| slaweq | looks good, thx bcafarel and ralonsoh | 15:04 |
| slaweq | so, next one | 15:04 |
| slaweq | ralonsoh to check UT failing with neutron-lib master | 15:04 |
| ralonsoh | done, one sec | 15:05 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron-lib/+/805395 | 15:05 |
| ralonsoh | and merged | 15:05 |
| ralonsoh | nonono | 15:05 |
| lajoskatona | salweq: You reported another one today: https://bugs.launchpad.net/neutron/+bug/1940905 | 15:05 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron-lib/+/804894 | 15:05 |
| ralonsoh | ^^ this patch | 15:05 |
| lajoskatona | I checked and based on opestack health page it looks ok, though I am not sure if openstack health is healthy.... | 15:06 |
| ralonsoh | there is patch for this bug | 15:06 |
| slaweq | thx ralonsoh for fixing that one bug | 15:06 |
| slaweq | lajoskatona yes, but I though it was failing even today and yesterday with this new issue | 15:07 |
| slaweq | let me check it | 15:07 |
| slaweq | https://zuul.openstack.org/build/7760210f28514e6fb3e0258cbfcbd4b8 | 15:07 |
| slaweq | see here | 15:07 |
| slaweq | it's from today morning | 15:07 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/805627 | 15:07 |
| ralonsoh | this patch | 15:07 |
| ralonsoh | that fixes the problem with the qos rule types constant | 15:08 |
| lajoskatona | ok | 15:08 |
| slaweq | ralonsoh and what about test_versions issue, like https://4982338ebecb97a12f63-bcc0089d8984128efe3d45fe2388916e.ssl.cf5.rackcdn.com/periodic/opendev.org/openstack/neutron/master/openstack-tox-py36-with-neutron-lib-master/a100726/testr_results.html ? | 15:08 |
| slaweq | it happened e.g. yesterday | 15:08 |
| lajoskatona | so openstack health is behind and out of sunc | 15:08 |
| lajoskatona | sync | 15:08 |
| slaweq | do You know what could cause this? | 15:08 |
| ralonsoh | slaweq, I think this problem is solved with https://review.opendev.org/c/openstack/neutron/+/805627 | 15:09 |
| slaweq | ok | 15:09 |
| slaweq | thx for taking care of it | 15:09 |
| slaweq | I will link that patch to that bug | 15:09 |
| slaweq | ok, that are all actions from last week | 15:10 |
| slaweq | let's move on | 15:10 |
| slaweq | #topic Stadium projects | 15:10 |
| slaweq | lajoskatona anything to discuss here? | 15:10 |
| lajoskatona | there's a few patches for tap-as-a-service | 15:10 |
| lajoskatona | i.e.: https://review.opendev.org/c/openstack/tap-as-a-service/+/803422 | 15:11 |
| lajoskatona | https://review.opendev.org/c/openstack/tap-as-a-service/+/804707 | 15:11 |
| lajoskatona | but otherwise quiet (except the vpnaas bug for memory leak) | 15:12 |
| slaweq | ok, I will review them tonight or tomorrow morning | 15:12 |
| bcafarel | half stadium and half stable, vpnaas gate fixes victoria https://review.opendev.org/c/openstack/neutron-vpnaas/+/803455 and ussuri https://review.opendev.org/c/openstack/neutron-vpnaas/+/746024 | 15:12 |
| bcafarel | lajoskatona: now that you are full stable core you can probably update your +1 there now :) | 15:12 |
| lajoskatona | bcafarel: yeah, I can, just seen that once I checked them :-) | 15:13 |
| slaweq | thx | 15:13 |
| slaweq | and ci of other stadium projects is ok, right? | 15:14 |
| slaweq | no new issues there I hope | 15:14 |
| lajoskatona | no | 15:14 |
| slaweq | great, thx lajoskatona | 15:14 |
| slaweq | let's move on | 15:14 |
| slaweq | #topic Stable branches | 15:14 |
| slaweq | bcafarel any new issues/updates? | 15:15 |
| bcafarel | overall it looks good, from what I checked since coming back from PTO | 15:15 |
| bcafarel | only the already mentioned https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/805864 | 15:15 |
| slaweq | thx | 15:16 |
| bcafarel | so overall you are leaving CI in nice shape for next PTL :) | 15:16 |
| slaweq | so let's move on | 15:16 |
| slaweq | #topic Grafana | 15:16 |
| slaweq | I was looking at dashboard today and I noticed that it's not up to date | 15:16 |
| slaweq | so I proposed https://review.opendev.org/c/openstack/project-config/+/805809 with many changes | 15:17 |
| slaweq | I will rebase it on top of obondarev's patch | 15:17 |
| slaweq | but please review it when You will have some time | 15:17 |
| amotoki | I noticed that functional job in neutorn-lib is covered last week. Is it better to add it? | 15:18 |
| amotoki | * in grafana | 15:18 |
| amotoki | woops ** is not covered | 15:19 |
| amotoki | I mean https://grafana.opendev.org/d/C5Wot6PMk/neutron-lib-failure-rate | 15:19 |
| slaweq | * amotoki TBH I didn't check that dashboard for long time :/ | 15:20 |
| slaweq | but yes, we should add it there | 15:20 |
| amotoki | hehe | 15:20 |
| slaweq | and probably also neutron-tempest-plugin-api as this also runs in neutron-lib gate/check | 15:20 |
| slaweq | I will do it | 15:21 |
| slaweq | thx amotoki | 15:21 |
| slaweq | #action slaweq to update neutron-lib grafana dashboard | 15:21 |
| slaweq | from other things I just noticed now that neutron-ovn-tempest-slow is going very high with failure rates | 15:22 |
| slaweq | did You maybe already checked it? | 15:22 |
| ralonsoh | one problem was related to the new image | 15:22 |
| bcafarel | I need to check some logs to confirm it, but probably same issue as seen in wallaby | 15:22 |
| ralonsoh | exactly | 15:23 |
| slaweq | Flavor with name ntp_image_384M already exists. | 15:23 |
| slaweq | yes | 15:23 |
| ralonsoh | (my bad...) | 15:23 |
| slaweq | ok, so we need to merge that bcafarel's fix fast | 15:23 |
| slaweq | and we should be good with that :) | 15:23 |
| slaweq | thx once again | 15:23 |
| slaweq | that's all from me regarding grafana | 15:24 |
| slaweq | and regarding other issues in functional/fullstack or tempest jobs, I didn't found anything new what we should discuss today | 15:24 |
| slaweq | in functional job we are still hitting the ovn related issue https://bugs.launchpad.net/neutron/+bug/1938766 | 15:25 |
| slaweq | from what jlibosva told me - that is most likely issue in openvswitch | 15:25 |
| slaweq | so he is going to check what earlier version of ovs we could use to unblock our gate | 15:26 |
| slaweq | and we will probably go with such workaround | 15:26 |
| slaweq | thx amotoki for help with that one too | 15:26 |
| slaweq | do You have any other issues You would like to discuss today? | 15:27 |
| ralonsoh | (I need to leave now, see you tomorrow) | 15:27 |
| slaweq | if not, I think we can all finish earlier and ralonsoh will be able to leave without losing anything :) | 15:27 |
| slaweq | see You ralonsoh | 15:27 |
| ralonsoh | heheh thanks | 15:27 |
| bcafarel | :) | 15:28 |
| slaweq | ok, I guess that this silence means "we want to go home now!!" :) | 15:29 |
| slaweq | so thx for attending the meeting today and see You all online | 15:30 |
| obondarev | \o/ | 15:30 |
| slaweq | #endmeeting | 15:30 |
| opendevmeet | Meeting ended Tue Aug 24 15:30:15 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:30 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-08-24-15.00.html | 15:30 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-08-24-15.00.txt | 15:30 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-08-24-15.00.log.html | 15:30 |
| lajoskatona | o/ | 15:30 |
| amotoki | o/ | 15:30 |
| bcafarel | o/ | 15:30 |
| thomasb06 | o/ | 15:31 |
| jlibosva | slaweq: btw about that issue - it's really related to the short living DB connections because of the pg_drop group | 15:32 |
| jlibosva | slaweq: I'm thinking about removing the short living connection because it causes issues at scale too | 15:35 |
| slaweq | jlibosva do we need those short living connections and pg_drop group creation in functional tests? maybe we could mock it there to workaround that issue? | 15:36 |
| jlibosva | slaweq: I'd like to remove the short living connections as a whole. It was a bad idea of mine :) | 15:37 |
| slaweq | jlibosva ok | 15:38 |
| *** rpittau is now known as rpittau|afk | 16:00 | |
| opendevreview | Merged openstack/neutron-vpnaas stable/ussuri: [stable/ussuri] Fix gates https://review.opendev.org/c/openstack/neutron-vpnaas/+/746024 | 16:01 |
| opendevreview | Merged openstack/neutron-vpnaas stable/victoria: Fix inconsistency in requirements https://review.opendev.org/c/openstack/neutron-vpnaas/+/803455 | 16:03 |
| opendevreview | Merged openstack/neutron stable/stein: Fix notify listener syntax for SEGMENT_HOST_MAPPING https://review.opendev.org/c/openstack/neutron/+/803738 | 20:38 |
| *** tbachman is now known as Guest5301 | 20:57 | |
| *** tbachman is now known as Guest5302 | 21:01 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!