Tuesday, 2023-01-24

opendevreviewMerged openstack/neutron master: [OVN] Add vnic_type and binding profile capabilities to LSP info  https://review.opendev.org/c/openstack/neutron/+/86735902:16
opendevreviewMerged openstack/neutron master: [OVN] Introduce the new OVN Neutron Agent  https://review.opendev.org/c/openstack/neutron/+/86990902:16
*** ges_ is now known as ges09:21
lajoskatonaralonsoh: Hi, gmann sent a mail regarding pypi extra maintainers over openstack-ci: https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031848.html09:26
lajoskatonaralonsoh: I added this topic to on-demand agenda of the meeting, and I updated the etherpad (https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup ), but would be good to discuss I think together09:27
ralonsohlajoskatona, did you add the names for the neutron related projects?09:29
gesHello! We are currently thinking about adding a little debugging endpoint to the agents, notably to be able to inspect the remote resource cache. For now it looks like a unix socket the agent listens on that answers to basic commands (dump_resource_cache, or run a pdb session). Do you think that could be of intereset upstream?09:32
ralonsohlajoskatona, anyway, thanks for this list, we'll review it today during the team meeting09:33
lajoskatonaralonsoh: I listed the stadiums or libs projects from the list, but perhaps I overlooked some :-)09:41
ralonsohlajoskatona, no no, that's ok. Thanks a lot09:41
ralonsohwe'll check this list later today in the meeting09:41
opendevreviewGregory Thiemonge proposed openstack/ovn-octavia-provider master: WIP Removing python-neutronclient code  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/87051409:49
ralonsohges, you can use https://github.com/openstack/nova/blob/master/doc/source/contributor/development-environment.rst#using-a-remote-debugger09:59
ralonsohor you can use https://docs.openstack.org/neutron/latest/contributor/policies/gate-failure-triage.html09:59
ralonsohusing pdb or rpdb for this09:59
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] New OVN Neutron Agent extension: QoS for HWOL  https://review.opendev.org/c/openstack/neutron/+/87011510:09
gesralonsoh: thanks! I've used remote pdb in some places, but it's often useless at detecting or working on an issue that goes away after restarting the agent. To give you an example, we sometimes lose messages in rabbitmq and we would want to check whether resources in the cache are in sync with the ones in DB. That's why we are thinking about a permanent endpoint and not some10:12
gesset_trace() we could add to the code here and there. I think it's a different use-case, no?10:12
ralonsohges, I don't think the community will agree on having an open backport for debugging. Maybe you can propose to have an API to retrieve from the neutron server what is the info in the agent10:13
ralonsohthis could be an idea10:13
ralonsohyou can propose it in a launchpad bug as a RFE10:14
ralonsohand propose it in the drivers meeting #10:14
ralonsoh#link https://meetings.opendev.org/#Neutron_drivers_Meeting10:14
amorinhey team10:16
amorinI am with ges involved in this topic, I fact we want something out of band, to collect metrics/status of the agent, without neutron-server involved10:16
amorinit looks like the oslo_messaging rpc_ping endpoint, which you we enabled to reach the agents without going through the server10:17
amorinbut this time, we want metrics10:17
ralonsohwhat metrics?10:18
amorinlike number of local lvm in lvm-manager10:18
amorinor version of objects in the remote-cache10:19
amorinwe started this because we found some inconsistencies within security groups, some of our agent were not managing them correctly10:19
amorinwhile we dont know yet the root cause, we wanted to dump the remote-cache live in order to see which agent is having which version of the objects10:20
ralonsohamorin, and how do you want to expose this debugging endpoint? do you want to be able to talk directly to the agent?10:22
ralonsohI don't think this is going to be allowed nor accepted10:22
amoringes implemented something based on a local socket10:22
ralonsohlike a pdb10:23
amorinyeah10:23
ralonsohyou can propose it but as commented, I don't think this will be accepted10:23
ralonsohthis is an official backdoor10:24
ralonsohand a security risk10:24
amorinof course, this should be secured and false by default10:26
amorinwe are preparing a paste to show you exemple10:27
amorinexample*10:27
gesI don't think it's a security risk more than say, having configuration files on the server, provided the socket has the correct rights.10:31
gesHere's the paste of what we came up with: https://paste.opendev.org/show/bsXrvJYFpIPnJhsN6bOi/10:34
lajoskatonages, ralonsoh, amorin: Hi, this idea looks passing to the healthcheck API10:41
lajoskatonages, ralonsoh, amorin: oslo-middlerware gives endpoint for this, but as I remember there is no pdb option for example10:42
lajoskatonages, ralonsoh, amorin: When I playedd with it a lot of debate come and we agreed to forget it, but would be interesting to check it again, see my patch and the comments on it:  https://review.opendev.org/c/openstack/neutron/+/73155410:43
amorinlajoskatona: this is a good idea what you propose, we are also doing that on our side with external tools (doing neutron agent list, checking RPC link, etc)10:46
amorinThis time, we want to have deeper "live" info about the agent10:46
opendevreviewLajos Katona proposed openstack/neutron-lib master: api-ref: Add dragent scheduler api-ref  https://review.opendev.org/c/openstack/neutron-lib/+/87058210:47
amorinanyway we are going to maintain something like this downstream, we just wanted to let you know and see if it could be benefit for the community as well10:48
geslajoskatona: It could fit there, but the healtcheck API doesn't seem to give any introspection capability. And I think it is really important for us to have an out-of-band solution.10:49
ralonsohges, amorin please propose this as a launchpad bug and in the drivers meeting11:02
opendevreviewMaurice Escher proposed openstack/neutron master: allow manila ports to do multiple port binding for ML2  https://review.opendev.org/c/openstack/neutron/+/86929512:42
opendevreviewLajos Katona proposed openstack/neutron master: Fullstack: Wait placement process fixtrue to really stop  https://review.opendev.org/c/openstack/neutron/+/87095613:42
opendevreviewLajos Katona proposed openstack/neutron master: Fullstack: Wait placement process fixtrue to really stop  https://review.opendev.org/c/openstack/neutron/+/87095613:53
*** dasm|off is now known as dasm13:58
ralonsohPING LIST SERVICE (provided by OpenStack): bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, sahid, slawek, tobias-urdin, ykarel, lajoskatona 13:59
ralonsoh1 min left to the Neutron meeting13:59
bcafarelfancy service :)13:59
ralonsohhehehe13:59
mlavallethank you ralonsoh 14:00
ralonsoh#startmeeting networking14:00
opendevmeetMeeting started Tue Jan 24 14:00:19 2023 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.14:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'networking'14:00
mlavalleo/14:00
ralonsohhello all14:00
obondarevhi14:00
haleybo/14:00
frickler\o14:00
lajoskatonao/14:00
ykarelo/14:00
slaweqo/14:00
ralonsohlet's start14:01
ralonsoh#topic announcements14:01
ralonsoh#link https://releases.openstack.org/antelope/schedule.html14:01
ralonsohwe are in R-814:01
ralonsohthree weeks before the A-3 milestone14:01
ralonsohthat is the feature freeze!14:02
ralonsohalong with the requirements and clients freeze14:02
ralonsohplease be aware of this14:02
ralonsohAlso please check the Openinfra presentations14:02
ralonsoh#link https://openinfra.dev/live/#all-episodes14:02
ralonsohthere is a new one14:03
ralonsohDistributing OpenStack Architecture with BGP and Kubernetes Integration14:03
ralonsoh#link https://www.youtube.com/watch?v=r8WLM9TM6w414:03
mlavalle++14:03
ralonsohit could be a bit scary, but this presentation provides a lot of information14:04
lajoskatonathanks the topic is really interesting and it is on my watch list 14:04
ralonsohand a very good starting point to know aboyt BGP (and kubernetes)14:04
ralonsohlet's move to the next topic then14:05
ralonsoh#topic bugs14:05
ralonsohthis is the report from jlibosva14:05
ralonsoh#link https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031868.html14:05
ralonsohmost of the bugs are attended now14:05
elvirahi, sorry for the delay o/ 14:05
ralonsohhi!14:05
ralonsohbut we have 2 of them still not assigned14:05
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/200353214:06
ralonsoh^^ for this one I'm spawning an env to try to reproduce it14:06
ralonsohbut I didn't have time to start with it14:06
ralonsohyou are welcome to check it too14:06
ralonsohthe second one14:07
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/200335914:07
ralonsohit seems to be a problem with a race condition14:07
ralonsohif you create and delete routers too fast14:07
ralonsohthere is also a reproducer, forcing a wait sleep during the GW port creation14:08
ralonsohcan anyone check this one?14:08
lajoskatonaI can check14:08
ralonsohlajoskatona, thanks a lot!14:08
ralonsohwe also have a new RFE but we'll talk about this one later14:09
ralonsohthis week obondarev is the deputy, next week will be isabek14:09
isabeko/14:09
obondarevyep, on it14:09
ralonsohthanks folks14:09
ralonsohok, I think we can move to the next topic14:10
ralonsoh#topic specs14:10
ralonsoh#link https://review.opendev.org/q/project:openstack%252Fneutron-specs+status:open14:10
ralonsohwe have a new one: https://review.opendev.org/c/openstack/neutron-specs/+/87003014:10
ralonsohthe RFE will be discussed this Friday14:10
ralonsoh#link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers14:11
ralonsohabout the second one https://bugs.launchpad.net/neutron/+bug/200309514:11
ralonsohI'll ping the reporter to have it discussed during the drivers meeting14:11
ralonsohso, in advance, please attend to the drivers meeting next Friday14:12
ralonsohanything else on this topic?14:12
ralonsohok, let's move to the next topic14:13
lajoskatonaJust a small one: the first patches are up for https://specs.openstack.org/openstack/neutron-specs/specs/2023.1/ovs-tx-steering.html so if you have time please check them (from rubasov :-)14:13
ralonsohI'm trying to find the links14:14
lajoskatonaI just found the api-def: https://review.opendev.org/c/openstack/neutron-lib/+/87008014:15
ralonsohok, it will be better to use the launchpad bug topic14:15
ralonsohlajoskatona, ok thanks a lot, I'll add it to my review pile14:16
lajoskatonathanks folks14:17
ralonsohlet's move to the next topic14:17
ralonsoh#topic community_goals14:17
ralonsoh1) Consistent and Secure Default RBAC14:17
ralonsoh#link https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/86751814:17
ralonsohslaweq, pushed a DNM patch using the new RBAC policies14:18
ralonsohdid you have time to check what is failing there?14:18
slaweqralonsoh not yet14:18
slaweqsorry14:18
ralonsohno no, no problem14:19
ralonsohbtw, will we have the new RBAC enforced this release?14:19
ralonsohI mean, we'll we swap to this by default?14:19
slaweqI'm not sure if it's not too late14:19
slaweqI will sync with gmann about it14:19
ralonsohI think so too14:19
ralonsohthanks!14:19
lajoskatonaif yes I suppose it will be a good release with nervous people running around :-)14:20
ralonsohyeah, I don't know the status of other projects14:20
ralonsohbut from Neutron point of view, we need to polish those failing tests14:20
ralonsohmost probably missing permissions, users, etc14:21
slaweqyes, it seems that mostly our internal RBAC isn't working fine with those new policies14:21
slaweqI will open bugs for that today or tomorrow so we can work on them14:21
ralonsohthat will be perfect14:22
ralonsohand thanks again14:22
ralonsohnext one14:22
ralonsoh2) Neutron client deprecation 14:22
ralonsoh#link https://review.opendev.org/q/topic:bug%252F199977414:23
lajoskatona+1, thanks for the link14:23
ralonsohI hope we have the trunk commands migrated and released soon14:23
ralonsohwe need another +2 in the SDK patch14:23
ralonsohand then we have the other sdk patch14:23
ralonsoh#link https://review.opendev.org/c/openstack/openstacksdk/+/86948514:23
mlavalleI can look at it today14:23
ralonsohthanks14:24
lajoskatonamlavalle: you also have +2 rights for SDK<14:24
lajoskatona?14:24
ralonsohthe SDK bgp patch is OK, IMO14:24
mlavallelajoskatona: ah no14:24
lajoskatona:-(14:24
ralonsohwe can ping stephenfin or Artem14:24
lajoskatonaI go and ask on sdk channel than to ask for review than14:24
ralonsohcool14:25
lajoskatonaralonsoh: ack14:25
ralonsohand again, thanks for working on this14:25
slaweqI have +2 in SDK repo, I will review it14:25
lajoskatonafrickler: if you can check the BGP patches that would be really helpful14:25
ralonsohah, btw, just asking14:25
ralonsohdo we want to push the patch removing all CLI from neutronclient?14:25
slaweqralonsoh I think it is time to do it finally14:26
ralonsoh(do we really need that? or we can wait until we definetly remove the repo)14:26
ralonsohok14:26
mlavalleI think so14:26
ralonsohI'll do it this week14:26
slaweqit was deprecated some time ago already14:26
slaweqralonsoh++14:26
fricklerlajoskatona: I'll be away for the coming two weeks, will have to wait until after that14:26
mlavallelajoskatona: would you give me again the pointer to the etherpad?14:26
lajoskatonafrickler: ack, not urgent I think, it will be a long story anyway :-)14:26
lajoskatonamlavalle: https://etherpad.opendev.org/p/python-neutronclient_deprecation14:27
mlavalleThanks!14:27
ralonsohI'll add this link to the bug14:27
lajoskatonaralonsoh: good idea, should have done that14:27
ralonsohdone14:28
lajoskatonathanks14:28
ralonsohand I think we are done here14:28
ralonsohthe last topic is14:28
ralonsoh#topic on_demand14:28
ralonsohlajoskatona, please14:28
lajoskatonathanks14:29
lajoskatonaI added one, gmann sent a mail regarding the maintainers on pypi: https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031848.html14:29
lajoskatonathere is an etherpad: https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup14:29
lajoskatonawhere I added our stadiums which suprisingly mostly have maintainers over openstack-ci14:30
lajoskatonaand the goal is today that QA (or TC) want to have only openstack-ci as maintainer for all openstack projects14:30
lajoskatonaI think this is a good goal, but as in the thread there are thngs which should be discussed14:31
opendevreviewArnaud Morin proposed openstack/neutron master: Set DVR qr-xyz interfaces DOWN on backup node  https://review.opendev.org/c/openstack/neutron/+/86974114:31
ralonsohbut if we have pypi mantainers, that means we'll have someone that can release without any permission from OpenStack 14:32
lajoskatonaif you check the etherpad some of the maintainers are now not active around openstack or Neutron, or even there is one really suspicious id (login.launchpad.net_179 )14:32
ralonsohyeah14:32
lajoskatonayes exactly, that happened with some horizon lib I think14:32
ralonsohchecking those Neutron related repos, all of them are actively mantained by the Neutron community14:33
ralonsohI don't think we should allow external maintainers14:33
obondarev+114:34
lajoskatonayes, and I hope that no deployment or build system depends in the outside world to have these rights for these people14:34
ralonsohfor example, we all now otherwiseguy is the father of ovsdbapp. But if he wants to push something, he know how to push a patch and release (in openstack) a new version14:34
lajoskatonaexactly14:34
ralonsohso if you agree, I'll add the comment "Ok to remove additional maintainers" to all Neutron related repos14:35
* otherwiseguy waves14:35
lajoskatonaand if there is some issue with the release the release team has the tools to fix it (I hope)14:35
ralonsohexactly14:35
lajoskatonaok, that was it from me to have a quick discussion of this topic14:35
ralonsohsorry, just for the records, do you mind to vote on this?14:35
amotokiI am fine with it. it is just because I created *-dashboard pypi projects per the project team guide14:36
lajoskatona+1 to keep only openstack-ci as maintainer14:36
lajoskatonaamotoki: thanks14:36
obondarevsame here, +114:36
ralonsohok, thanks, I'll update the etherpad14:37
ralonsohand I have another topic14:37
ralonsoh#link https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031745.html14:37
ralonsohthis is related to the in-person PTG14:38
ralonsohwe know we have, at least this year, two virtual PTGs14:38
mlavalle+114:38
ralonsohthe point here is what about the Vancouver event?14:38
ralonsohwhat should be the agenda?14:39
mlavalleat the very least pizza and beer14:39
ralonsohyou have proposed to have a lighweight agenda for this event14:39
slaweqmlavalle++14:39
ralonsohmlavalle, yeah but this is difficult to be justified14:39
lajoskatonaShall we open an etherpad and collect topics?14:39
mlavallejokes aside, meeting in person is necessary after such a long time14:40
ralonsohI mean, if we don't have a good planned agenda, this year (14:40
slaweqand seriously, for sure some "feedback from operarors" or something like that14:40
ralonsohlajoskatona, yes, that could be a very good starting point14:40
ralonsohslaweq, yes, this is another good topic14:40
ralonsoheven better is that is done in person14:40
ralonsohok14:40
ralonsohI'll reply to the mail chain14:40
mlavalleralonsoh: do we have a deadline for an agenda?14:40
ralonsohand the first think I'll do is to create this etherpad14:41
ralonsohnot really, I will ask TC folks14:41
lajoskatonathanks14:41
ralonsohbut just remember this Vancouver event is in june (13-15)14:41
mlavalleso I'm pretty sure we can como up with an agenda that includes operators feedback, pizaa / beer and more topics14:42
lajoskatonayeah, we started to beg for travel budget :-)14:42
ralonsohlajoskatona, exactly! (and this is a very accurate verb)14:42
mlavallelet's start with the etherpad now14:42
ralonsohI'll do it tomorrow morning, I'll send a mail14:42
ralonsohand thanks for the feedback!14:43
lajoskatonaSorry I have to run for my kid to school, o/14:43
ralonsohsure14:43
ralonsohI think we don't have nothing else in the agenda14:43
ralonsohso thank you all for attending14:43
ralonsohand remember today we don't have the CI meeting14:43
ralonsohsee you online!14:43
obondarevo/14:43
ralonsoh#endmeeting14:43
opendevmeetMeeting ended Tue Jan 24 14:43:52 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:43
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2023/networking.2023-01-24-14.00.html14:43
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2023/networking.2023-01-24-14.00.txt14:43
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2023/networking.2023-01-24-14.00.log.html14:43
opendevreviewBrian Haley proposed openstack/neutron master: Change flag check order in wait_until_address_ready()  https://review.opendev.org/c/openstack/neutron/+/87138914:46
mlavalleo/14:47
opendevreviewRodolfo Alonso proposed openstack/neutron stable/xena: Since OVN 20.06, config is stored in "Chassis.other_config"  https://review.opendev.org/c/openstack/neutron/+/87163715:30
opendevreviewRodolfo Alonso proposed openstack/neutron stable/wallaby: Since OVN 20.06, config is stored in "Chassis.other_config"  https://review.opendev.org/c/openstack/neutron/+/87164016:20
opendevreviewRodolfo Alonso proposed openstack/neutron stable/wallaby: Since OVN 20.06, config is stored in "Chassis.other_config"  https://review.opendev.org/c/openstack/neutron/+/87164016:44
opendevreviewRodolfo Alonso proposed openstack/neutron stable/xena: Since OVN 20.06, config is stored in "Chassis.other_config"  https://review.opendev.org/c/openstack/neutron/+/87163716:46
opendevreviewRodolfo Alonso proposed openstack/neutron stable/wallaby: Since OVN 20.06, config is stored in "Chassis.other_config"  https://review.opendev.org/c/openstack/neutron/+/87164016:47
opendevreviewJakub Libosvar proposed openstack/neutron master: ovn-migration: Don't clone interfaces to br-migration  https://review.opendev.org/c/openstack/neutron/+/87165017:52
opendevreviewMerged openstack/neutron-lib master: add DEVICE_OWNER_MANILA_PREFIX to constants  https://review.opendev.org/c/openstack/neutron-lib/+/86929418:38
opendevreviewBrian Haley proposed openstack/neutron master: Add doc note on nf_conntrack module requirement  https://review.opendev.org/c/openstack/neutron/+/87165920:19
*** dasm is now known as dasm|off23:09

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!