14:00:32 <slaweq> #startmeeting networking
14:00:32 <opendevmeet> Meeting started Tue Sep  7 14:00:32 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:32 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:32 <opendevmeet> The meeting name has been set to 'networking'
14:00:34 <slaweq> hi
14:00:35 <mlavalle> o/
14:00:44 <ralonsoh> hi
14:00:48 <haleyb> hi
14:00:58 <elvira> hi
14:01:00 <bcafarel> o/
14:01:18 <rubasov> o/
14:01:18 <liuyulong> hi there
14:01:25 <lajoskatona> Hi
14:02:17 <slaweq> ok, let's start
14:02:22 <slaweq> #topic Announcements
14:02:29 <slaweq> Xena cycle calendar https://releases.openstack.org/xena/schedule.html
14:02:33 <slaweq> we are almost there
14:02:36 <obondarev> hi
14:02:54 <slaweq> last week we reached Xena-3 milestone and we did final release for python-neutronclient
14:03:03 <slaweq> next week is Xena RC-1 week
14:03:17 <slaweq> so we should focus now on bug fixes, not new RFEs
14:03:47 <slaweq> next one
14:03:55 <slaweq> October PTG
14:03:55 <opendevreview> liuyulong proposed openstack/neutron-lib master: Leave *_ALL_TABLES to Neutron  https://review.opendev.org/c/openstack/neutron-lib/+/807224
14:03:56 <slaweq> etherpad https://etherpad.opendev.org/p/neutron-yoga-ptg
14:04:19 <slaweq> please add Your topics there :)
14:04:52 <slaweq> and that are basically all announcements from me today
14:05:30 <slaweq> anything else You want to announce/remind to the team?
14:06:50 <slaweq> if not, let's move on
14:06:55 <slaweq> #topic Blueprints
14:07:06 <liuyulong> I have one.
14:07:14 <slaweq> sorry liuyulong
14:07:16 <slaweq> go on
14:07:45 <liuyulong> Since, there is few people to attend neutron L3 meeting, maybe we can merge it to the team meeting.
14:08:13 <slaweq> I'm fine with that
14:08:19 <liuyulong> I had some one person meetings. : )
14:08:59 <ralonsoh> I'm ok with this
14:09:02 <slaweq> but I think it's more decision of the "ptl elect" now :)
14:09:02 <liuyulong> And I noticed that some bugs were discussed in team meeting as well.
14:09:26 <lajoskatona> as I remember we touched this on one of the l3 meetings, I am fine with it
14:09:51 <liuyulong> As in L3 meeting, we mostly are talking about bugs. : )
14:10:04 <slaweq> if there is nobody agains, I will add it as a topic in the team meeting and will propose removal of L3 subteam meeting
14:11:39 <liuyulong> OK, I think we have a sonsensus then. : )
14:11:51 <mlavalle> +1
14:11:51 <slaweq> yes, thx liuyulong for bringing it up to the discussion
14:12:05 <slaweq> let's get back to the BPs
14:12:07 <liuyulong> s/consensus
14:12:37 <slaweq> I already moved all not finished BPs from Xena-3 to neutron-next now
14:12:46 <slaweq> as we agreed last week
14:13:18 <slaweq> I don't think we have a lot to discuss about BPs today but if anyone has got any updates/questions, feel free to raise it now
14:14:37 <slaweq> ok, I guess this means "no updates" for today
14:14:40 <slaweq> so let's move on
14:14:49 <slaweq> #topic Bugs
14:15:04 <slaweq> haleyb: You were bug deputy, any bugs to discuss now?
14:15:27 <haleyb> There was one critical bug i left off the email since i thought it was embargoed
14:15:30 <haleyb> https://bugs.launchpad.net/neutron/+bug/1942179
14:15:39 <haleyb> but it's not now and the fix has merged
14:15:48 <haleyb> guess the bot isn't working
14:16:02 <haleyb> "neutron api worker leaks memory when processing requests to not existing controllers"
14:16:26 <slaweq> its status is "fix released" now I see
14:16:45 <haleyb> thanks for the fix slaweq  :)
14:16:50 <slaweq> and backports are proposed to stable branches also
14:16:51 <slaweq> yw
14:17:03 <slaweq> thx ralonsoh for help debugging that issue, it was funny one :)
14:17:09 <ralonsoh> for sure
14:17:15 <amotoki> I really wonder how you identified the cause of this
14:18:15 <ralonsoh> slaweq found the cause and I debugged the issue, finding the leak in this evenlet local var
14:18:19 <slaweq> amotoki: I was going through different places in code from stacktrace, starting where that log about 404 was logged
14:19:06 <slaweq> we were trying various things but finally we narrowed it down by simple trying to skip parts of the code and seeing if issue still happens or not
14:19:14 <slaweq> and if not, then going deeper there
14:20:05 <haleyb> there was one bug about RBAC and SGs that might require discussion, or at least there was a question at the end so i'll raise it here
14:20:09 <haleyb> https://bugs.launchpad.net/neutron/+bug/1942615
14:20:18 <haleyb> "SG shared through RBAC mechanism can't be used to spawn instances"
14:20:26 <slaweq> thx haleyb :)
14:20:34 <slaweq> actually I wanted to raise it here too
14:21:01 <haleyb> slaweq: all yours
14:21:05 <slaweq> please read the bug description, main question is there actually
14:21:28 <slaweq> I was trying to explain it there but if something is not clear, please ask now :)
14:21:54 <ralonsoh> I agree with not changing the API but adding an additional parameter (that implies a change in Nova and Neutron)
14:22:35 <slaweq> there is also one more possibility which I didn't mentioned in the bug description
14:22:41 <slaweq> but we discussed it yesterday with ralonsoh
14:23:11 <slaweq> we can document, that if user wants to use shared SG, first he should create port with that SG using neutron API
14:23:12 <amotoki> this issue sounds similar to a topic on all_projects=true/false behavior related horizon network listing dsicussed in the recent meetings
14:23:24 <slaweq> and then pass port to the nova API
14:23:43 <slaweq> that way no changes in code would be required
14:23:43 <amotoki> tenant_id filter was added to nova due to listing with admin roles in neutron API
14:24:21 <ralonsoh> amotoki, kind of, the goal is to list everything related to a single project but including the shared SGs to this project
14:24:49 <amotoki> ralonsoh: exactly. perhaps I understand the problem
14:25:28 <lajoskatona> To document to create port with SG sounds reasonable as for QoS the WoW is the same for minimum bandwidth
14:25:31 <amotoki> tenant_id filter is used to avoid all SG from all projects when the API is called with admin role but it is not friendly with RBAC mechanism
14:26:08 <slaweq> amotoki: that's true
14:28:32 <amotoki> introducing all_projects filter to the listing API would work. when all_projects=false is specifed, the API can return all resources visible to the project (without admin-ness)
14:29:13 <ralonsoh> but admin will see everything
14:29:23 <amotoki> all_projects=true keeps the current behavior including specifying project_id/tenant_id filter.
14:29:36 <ralonsoh> perfect then
14:29:45 <ralonsoh> that could work, yes
14:30:11 <slaweq> so in nova we would need to change request to be done with all_projects=false
14:30:17 <slaweq> and without tenant_id filter
14:30:19 <slaweq> right?
14:30:39 <amotoki> slaweq: that is what in my mind
14:31:13 <slaweq> that could work indeed
14:31:28 <slaweq> but it will work only when ralonsoh will implement his "all_projects" RFE
14:31:32 <slaweq> it was on you ralonsoh, right?
14:31:39 <ralonsoh> ?
14:31:50 <ralonsoh> not really
14:31:54 <slaweq> hmm
14:31:55 <slaweq> ok
14:32:31 <slaweq> I think we discussed something similar recently
14:32:34 <slaweq> wasn't that RFE?
14:32:53 <slaweq> I will need to look for it in the meetings' logs
14:33:01 <ralonsoh> sorry I'm lost here
14:33:03 <amotoki> another solution is to allow users to query resources with shared=true (resources shared by RBAC)
14:33:29 <ralonsoh> this is more explicit
14:33:45 <opendevreview> Merged openstack/neutron stable/wallaby: Don't use singleton in routes.middleware.RoutesMiddleware  https://review.opendev.org/c/openstack/neutron/+/807632
14:33:48 <opendevreview> Merged openstack/neutron stable/victoria: Don't use singleton in routes.middleware.RoutesMiddleware  https://review.opendev.org/c/openstack/neutron/+/807633
14:33:59 <opendevreview> Merged openstack/neutron stable/ussuri: Remove dhcp_extra_opt value after first newline character  https://review.opendev.org/c/openstack/neutron/+/806750
14:34:08 <amotoki> IIRC shared attribute is not avaialbe for all resources with RBAC support so it would be more straight-forward
14:34:10 <opendevreview> Merged openstack/neutron master: Skip FIP check if VALIDATE_MIGRATION is not True  https://review.opendev.org/c/openstack/neutron/+/806942
14:34:22 <amotoki> s/so/but/
14:35:15 <amotoki> and this solution would still require double APi listing calls (but it would be a good short-term solution)
14:35:49 <ralonsoh> just one qq: when using all_projects and tenant_id, how can admin user retrieve only its own SG+shared?
14:36:37 <opendevreview> Merged openstack/neutron-lib master: Improve "get_collection_count" method  https://review.opendev.org/c/openstack/neutron-lib/+/807686
14:37:47 <amotoki> ralonsoh: it cannot even with all_projects=false withotu tenant_id. if we really need this, 'shared' filter would be required.
14:38:01 <amotoki> that is my quick thought but i might be wrong.
14:38:08 <opendevreview> Lucas Alvares Gomes proposed openstack/neutron stable/wallaby: Skip FIP check if VALIDATE_MIGRATION is not True  https://review.opendev.org/c/openstack/neutron/+/807735
14:38:15 <ralonsoh> this is what I was thinking
14:38:21 <opendevreview> Lucas Alvares Gomes proposed openstack/neutron stable/victoria: Skip FIP check if VALIDATE_MIGRATION is not True  https://review.opendev.org/c/openstack/neutron/+/807736
14:38:28 <ralonsoh> so I think we should propose "shared" flag
14:38:36 <opendevreview> Lucas Alvares Gomes proposed openstack/neutron stable/ussuri: Skip FIP check if VALIDATE_MIGRATION is not True  https://review.opendev.org/c/openstack/neutron/+/807737
14:38:59 <amotoki> ralonsoh: good idea. looks straight-forward
14:39:10 <slaweq> and then we would need to modify nova to make additional API request for shared SGs when it will not find anything in own tenant, right?
14:39:58 <amotoki> perhaps yes
14:40:07 <slaweq> ok, sounds reasonable for me
14:40:24 <slaweq> I will propose docs update for now to document how it can be used currently
14:40:30 <opendevreview> Lucas Alvares Gomes proposed openstack/networking-ovn stable/train: Skip FIP check if VALIDATE_MIGRATION is not True  https://review.opendev.org/c/openstack/networking-ovn/+/807738
14:40:34 <slaweq> and then will work on that "shared" filter in next cycle
14:40:44 <slaweq> will that works for You?
14:40:50 <amotoki> yes
14:41:26 <ralonsoh> yes
14:41:35 <slaweq> ++
14:41:36 <lajoskatona> +1
14:41:37 <slaweq> thx a lot
14:41:56 <slaweq> haleyb: any other bugs to discuss today?
14:42:16 <haleyb> slaweq: you had a wishlist bug, i'll mention but maybe people can just discuss in bug
14:42:19 <haleyb> https://bugs.launchpad.net/neutron/+bug/1942294
14:42:29 <haleyb> "Is allow_overlapping_ips config option still needed really?"
14:42:42 <slaweq> ahh, right
14:42:47 <slaweq> I almost forgot about it :)
14:43:07 <haleyb> i don't know myself if anyone uses that, but *think* most people set it to True, right?
14:43:09 <slaweq> I recently noticed we have that option in Neutron still but do You know if it is used for anything still?
14:44:29 <ralonsoh> right, I think this is useless since Nova removed all network related
14:44:45 <obondarev> +1
14:44:51 <amotoki> I cannot remember the history and the exact context. haleyb cannot remember it either. I will comment in the bug after checking it.
14:45:19 <slaweq> do You think we can still deprecate it that cycle?
14:45:28 <slaweq> or should we wait with that to Yoga?
14:45:41 <lajoskatona> As nova networking was removed from nova, we can remove it as I see
14:45:50 <ralonsoh> +1
14:45:58 <amotoki> I think we can deprecate it. If someone depends on it, they can report/raise it
14:46:11 <amotoki> * deprecate it in this cycle
14:46:12 <haleyb> my only suggestion would be to make the code as if it's set to True
14:46:23 <haleyb> i.e. there is a single 'if' in neutron
14:46:31 <ralonsoh> right
14:47:03 <obondarev> default is False
14:47:17 <slaweq> haleyb: what do You think by "make the code as it's set to True"?
14:47:46 <haleyb> slaweq: in the ipam code use
14:47:49 <haleyb> subnet_list = [{'id': s.id, 'cidr': s.cidr}
14:47:49 <haleyb> for s in network.subnets]
14:48:05 <amotoki> https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L244-L248
14:48:06 <ralonsoh> "false" was the safe value but Neutron supports this
14:48:11 <haleyb> afaik distros set it to True, right?
14:48:12 <ralonsoh> and Nova does not care
14:48:24 <slaweq> yes, all tools which I saw sets it to true
14:48:41 <slaweq> ok, I will mark option as deprecated and will change code in neutron so it will be run as
14:48:48 <slaweq> it's set to True
14:49:03 <slaweq> thx for the comments on that
14:49:14 <haleyb> +1
14:50:02 <slaweq> any other bugs for today? :)
14:50:31 <haleyb> no, fixes proposed for everything else i think, that's all i had
14:50:52 <slaweq> thx haleyb
14:51:07 <slaweq> this week our bug deputy is lajoskatona
14:51:22 <slaweq> next week will be amotoki - is that ok for You amotoki?
14:51:33 <amotoki> yes. I will be on vacation till next Mon and be back next Tue. I can cover most of the week so it would not be a problem.
14:51:53 <slaweq> thx
14:52:07 <slaweq> so that's all regarding bugs for today
14:52:12 <slaweq> #topic On Demand Agenda
14:52:18 <slaweq> I have one more quick topic for today
14:52:24 <slaweq> Rehome ovs constants to neutron-lib https://review.opendev.org/q/topic:%22rehome-ovs-constants%22+(status:open%20OR%20status:merged)
14:52:30 <slaweq> there are some patches proposed by me there
14:52:39 <slaweq> and liuyulong has different opinion about it
14:52:48 <slaweq> I wanted to discuss it with the team
14:53:13 <slaweq> should we rehome those constants to neutron-lib? wdyt?
14:53:38 <liuyulong> Surely, I moved some comments to commit message of this patch https://review.opendev.org/c/openstack/neutron-lib/+/807224
14:53:57 <ralonsoh> yes, n-lib should be the place for those constants. About speeding up the development, you can always add new constants to Neutron with a TODO to rehome them later
14:54:18 <ralonsoh> that will allow you to send patches to Neutron without waiting for n-lib
14:54:18 <amotoki> yes, I am personally fine with this as OVS constants are used in various repos as we had discussions before.
14:54:30 <amotoki> can we move them to neutron_lib.constants to more a specific place?
14:54:37 <amotoki> neutron_lib.constants grows
14:54:41 <ralonsoh> agree
14:55:18 <lajoskatona> +1, I undesratnd that with n-lib releases can be harder to work, but it's a place where Neutron related things are collected to one repo
14:55:21 <liuyulong> How to deal with the problems of these cases? ralonsoh
14:55:28 <liuyulong> 1. Since the qos "VALID_RULE_TYPES" is moved to neutron-lib,
14:55:28 <liuyulong> we have done some extra works:
14:55:28 <liuyulong> a. copy the new list back, do the Neutron only development works [1].
14:55:28 <liuyulong> b. move the list back to neutron-lib [2]
14:55:28 <liuyulong> c. waiting for neutron-lib to have a new release [3]
14:55:29 <liuyulong> d. update neutron to use constants from neutron-lib  [4]
14:55:30 <liuyulong> 2. They are going to move the "*_BR_ALL_TABLES" to neutron-lib [5],
14:55:32 <liuyulong> and doing the same work of rotating Neutron [6]. For these tables,
14:55:34 <liuyulong> at least two WIP features will have works on these tables [7][8].
14:55:36 <liuyulong> So, let them copy these list back to neutron again? Then add a
14:55:38 <liuyulong> TODO node? It wastes not only developer time, but also code
14:55:42 <liuyulong> reviewers bandwidth.
14:55:44 <liuyulong> [1] https://review.opendev.org/c/openstack/neutron/+/796363/15/neutron/services/qos/constants.py
14:55:46 <liuyulong> [2] https://review.opendev.org/c/openstack/neutron-lib/+/804378
14:55:48 <liuyulong> [3] https://review.opendev.org/c/openstack/neutron/+/803462
14:55:50 <liuyulong> [4] https://review.opendev.org/c/openstack/neutron/+/804380
14:55:52 <liuyulong> [5] https://review.opendev.org/c/openstack/neutron/+/797121/8/neutron/plugins/ml2/drivers/openvswitch/agent/common/constants.py#b1
14:55:55 <liuyulong> [6] https://review.opendev.org/c/openstack/neutron/+/797120/
14:55:57 <liuyulong> [7] https://review.opendev.org/c/openstack/neutron-specs/+/797798/12/specs/xena/node-local-ip.rst@259
14:56:00 <liuyulong> [8] https://review.opendev.org/c/openstack/neutron/+/804213
14:56:23 <ralonsoh> of course we don't have time in this meeting to review all of this
14:56:31 <ralonsoh> I'll reply on the reviews
14:56:40 <liuyulong> The main problem is how to define "common use"?
14:56:59 <liuyulong> A list of constants is "common used"?
14:57:03 <ralonsoh> in this specific case: OVS constants are "common use"
14:57:14 <liuyulong> A list of constants which is used only by Neutron is "common used"?
14:57:19 <ralonsoh> other plugins should be aware of OVS trables, OFs, etc
14:57:46 <amotoki> at least we had an example on OVS tables. it is better to define table numbers in a single place.
14:58:00 <liuyulong> sure, see the commit message here, https://review.opendev.org/c/openstack/neutron-lib/+/807224
14:58:13 <liuyulong> I just move all the arguments here.
14:58:31 <liuyulong> amotoki, it's fine to place one singe table to neutron-lib.
14:59:01 <slaweq> we are almost out of time, let's continue it in the review of the patches
14:59:05 <liuyulong> But, the combination list if "_ALL_TABLE" is used by neutron only.
14:59:09 <slaweq> at least team is aware of that :)
14:59:35 <slaweq> thx for attending the meeting
14:59:39 <slaweq> have a great week :)
14:59:45 <slaweq> #endmeeting