14:00:47 <slaweq> #startmeeting networking
14:00:49 <openstack> Meeting started Tue Mar 16 14:00:47 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:50 <slaweq> hi
14:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:53 <openstack> The meeting name has been set to 'networking'
14:01:16 <mlavalle> o/
14:01:26 <slaweq> o/
14:01:31 <rubasov> hi
14:01:58 <obondarev> hi
14:02:03 <haleyb> hi
14:02:42 <slaweq> let's start
14:02:45 <slaweq> #topic announcements
14:02:47 <lajoskatona> Hi
14:02:55 <slaweq> Wallaby cycle calendar https://releases.openstack.org/wallaby/schedule.html
14:03:01 <slaweq> next week is RC1 week
14:03:16 <slaweq> so we are almost there with Wallaby
14:03:21 <slaweq> release highlights merged https://review.opendev.org/c/openstack/releases/+/779487
14:03:32 <ralonsoh> hi (sorry for being late)
14:03:33 <slaweq> we also have accepted RFE for new neutron-lib release for Wallaby: http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021077.html
14:03:53 <slaweq> release patch was just approved by release team https://review.opendev.org/c/openstack/releases/+/780550
14:04:35 <slaweq> we are now after feature freeze deadline so please don't accept patches related to any new features in next weeks
14:04:52 <slaweq> we can accept such patches after we will have stable/wallaby branch created
14:05:23 <slaweq> next reminder is about PTG which will be 19-23th April: http://lists.openstack.org/pipermail/openstack-discuss/2021-March/020778.html
14:05:49 <slaweq> Doodle https://doodle.com/poll/cc2ste3emzw7ekrh?utm_source=poll&utm_medium=link is still active, if You haven't fill it yet, please do so
14:06:12 <slaweq> next week is deadline for booking virtual rooms for the team
14:06:40 <slaweq> there is also etherpad https://etherpad.opendev.org/p/neutron-xena-ptg created
14:07:02 <slaweq> if You have any proposals for topics to discuss during the PTG, please add them there
14:07:21 <slaweq> ok, next one
14:07:33 <slaweq> PTL nominations are now over
14:07:48 <slaweq> there was only one candidate for the Neutron PTL so there is no election
14:08:09 <slaweq> and You will have to live with me one more cycle :)
14:09:18 <mlavalle> Thanks for being our PTL another cycle!
14:09:33 <slaweq> thanks mlavalle
14:09:37 <obondarev> thanks Slawek!
14:09:44 <slaweq> thx :)
14:09:54 <slaweq> that are all announcements from today from me
14:10:07 <slaweq> do You have anything else to add/announce to the team?
14:11:01 <mlavalle> not me
14:11:06 <slaweq> ok, I guess that this means "no"
14:11:13 <slaweq> so let's move forward
14:11:21 <slaweq> #topic Blueprints
14:11:25 <slaweq> Wallaby RC1 https://bugs.launchpad.net/neutron/+milestone/wallaby-rc1
14:12:01 <slaweq> I today set https://blueprints.launchpad.net/neutron/+spec/address-groups-in-sg-rules as implemented
14:12:35 <slaweq> and I moved other BPs to neutron-next as we don't have any BP for RC1
14:12:47 <mlavalle> +1
14:13:03 <slaweq> thx mlavalle and Your team for working on that address-groups BP
14:13:23 <slaweq> one more update from me, regarding secure-rbac
14:13:25 <slaweq> https://blueprints.launchpad.net/neutron/+spec/secure-rbac-roles
14:13:26 <mlavalle> Thanks to hangyang
14:13:39 <slaweq> we have merged all patches which introduced new policies
14:13:46 <slaweq> so we have that in neutron for Wallaby
14:14:39 <slaweq> lbragstad found bug related to the access of the resources by system reader
14:15:07 <slaweq> https://bugs.launchpad.net/neutron/+bug/1918506
14:15:09 <openstack> Launchpad bug 1918506 in neutron "Neutron doesn't honor system-scope" [High,Fix committed] - Assigned to Slawek Kaplonski (slaweq)
14:15:30 <slaweq> fix is in neutron lib and that's why we needed that new release of neutron-lib
14:16:30 <slaweq> there is also additional issue with those roles, that project admin was able to get e.g. system resources which should be available only for system admin/reader
14:16:35 <slaweq> like e.g. list of agents
14:16:43 <slaweq> fix for that is proposed https://review.opendev.org/c/openstack/neutron/+/780548
14:17:39 <slaweq> please review that patch when You will have some time
14:18:03 <slaweq> today I found one more thing with those new personas
14:18:09 <slaweq> this time about network creation
14:18:25 <slaweq> new rules allows create e.g. provider network only for system admin: https://github.com/openstack/neutron/blob/5f6fbcb155e19d0a46cef0e7bbfee553f0472ef3/neutron/conf/policies/network.py#L123 - in context of such system admin user, there is no project_id, so such admin needs always to pass --project_id to specify owner of the network - should we allow it also for project_admin?
14:19:12 <ralonsoh> how can you know he is a project_admin without project id?
14:19:27 <slaweq> project_admin is different role
14:19:48 <ralonsoh> yes, but project_admin is the admin of a single project
14:19:54 <ralonsoh> and you don't have it
14:20:24 <slaweq> so system_admin is role which is set when there is system_scope='all' in context and there is no project_id then
14:20:44 <slaweq> but project_admin is role where in context IS project_id given
14:20:57 <slaweq> https://github.com/openstack/neutron/blob/master/neutron/conf/policies/base.py#L60
14:21:14 <slaweq> so the issue is that
14:22:05 <slaweq> 1. with old rules there was only one type of ADMIN and such admin user belong to some tenant always, so when such user created network with e.g. provider_network given it was fine as tenant_id was in context
14:23:02 <slaweq> 2. now, with new rules we set that such call with provider:physical_network can be done just by SYSTEM_ADMIN and when such user makes API request there is no tenant_id in context
14:23:14 <slaweq> so neutron fail as it needs tenant_id for network
14:23:22 <slaweq> so there are 2 possibilities IMO:
14:23:55 <slaweq> a) we leave it as it is now and update our docs that such SYSTEM_ADMIN user needs to always pass tenant-id for which network is created
14:24:30 <slaweq> b) we will modify our new policy rules to allow creation of e.g. network with provider:physical_network also for users with role PROJECT_ADMIN
14:24:48 <ralonsoh> a) that's safe but changes the API
14:24:53 <slaweq> is the problem clear now?
14:24:56 <ralonsoh> b) is less secure but no API change
14:25:06 <slaweq> ralonsoh: yes, exactly
14:25:18 <slaweq> b) mimics what we have now with "less secure rules"
14:25:29 <ralonsoh> to avoid API changes (and problems), I would prefer b)
14:25:32 <slaweq> by "less secure" I mean old rules
14:25:36 <ralonsoh> I know
14:25:43 <ralonsoh> we can improve that later
14:26:13 <slaweq> of course user can modify it on own deployment, it's just matter of defaults
14:26:31 <slaweq> I have patch for option b) ready but I wanted to know Your opinion first
14:27:09 <lajoskatona> if I understand well b) is like what we have now
14:27:16 <mlavalle> and we should probably document profusely if we go with b
14:27:24 <slaweq> lajoskatona: more or less - yest
14:27:26 <slaweq> *yes
14:27:27 <lajoskatona> I mean before the policy cahnges merged (victoria and before)
14:28:06 <lajoskatona> so b) looks like a way forward but worth a mail perhaps to list
14:28:21 <ralonsoh> agree
14:28:29 <slaweq> mail about what exactly?
14:28:46 <ralonsoh> (anyway, if I prefer (b) now is for not changing the API jsut right now, at the end of the cycle)
14:28:47 <slaweq> that we will go with "less secure" default rules to mimic old behaviour?
14:28:56 <lajoskatona> exactly
14:29:13 <slaweq> ralonsoh: TBH by default old, deprecated rules are still working fine
14:29:26 <lajoskatona> we keep the old behaviour with API but from the new rules perspective it is less secure
14:29:36 <slaweq> so API isn't really changed until You will not switch some config knobs to enable usage of new rules only
14:29:51 <ralonsoh> what lajoskatona said
14:30:04 <ralonsoh> new rules but same policing
14:30:15 <slaweq> ok, I will send that patch to mimic old rules in new ones as much as possible
14:30:28 <slaweq> we can improve/change them in the future if there will be need for that
14:30:35 <slaweq> thx for Your opinions about it
14:31:45 <slaweq> and with that I think we are done with BPs for today
14:31:54 <slaweq> do You want to talk about any other BP?
14:33:13 <slaweq> ok, let's move on
14:33:21 <slaweq> #topic Community Goals
14:33:32 <slaweq> ralonsoh: any updates about privsep migration?
14:33:46 <ralonsoh> not for now
14:33:53 <slaweq> k
14:34:00 <slaweq> so we can move on to the next topic
14:34:07 <slaweq> #topic Bugs
14:34:17 <slaweq> hongbin was bug deputy, report: http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021064.html
14:34:39 <slaweq> I see there 2 bugs which needs some attention
14:34:44 <slaweq> https://bugs.launchpad.net/neutron/+bug/1918914 - ovn and DHCP issue
14:34:45 <openstack> Launchpad bug 1918914 in neutron "Toggling dhcp on and off in a subnet causes new instances to be unreachable" [Medium,Confirmed]
14:34:52 <slaweq> ralonsoh I saw You were commenting on it
14:34:58 <slaweq> will You take care of that LP?
14:35:27 <ralonsoh> slaweq, ok but I still can't reproduce it
14:35:37 <slaweq> yes, I saw
14:35:50 <ralonsoh> I don't know why is confirmed (even with c#3)
14:35:59 <slaweq> please keep an eye on it, maybe there will be some more data about how to reproduce it
14:36:01 <ralonsoh> in any case, I'll check it
14:36:05 <slaweq> thx a lot
14:36:14 <slaweq> and second one is
14:36:17 <slaweq> https://bugs.launchpad.net/neutron/+bug/1918145 - API slowdown
14:36:18 <openstack> Launchpad bug 1918145 in neutron "Slownesses on neutron API with many RBAC rules" [Medium,Confirmed]
14:36:30 <slaweq> obondarev I was hoping that maybe You could take a look at that one
14:36:45 <slaweq> as You are doing a lot of performance improvements on API/DB level recently :)
14:37:34 <obondarev> @slaweq, yes, this is part of internal activity. Let me check that one. Not promising however I'll have enough time for this in coming days :)
14:37:50 <slaweq> obondarev: thank You
14:38:15 <slaweq> other bugs from the report are at least assigned as far as I checked
14:38:21 <slaweq> so we should be good with them
14:38:29 <slaweq> this week our bug deputy is haleyb :)
14:38:36 <slaweq> and next week will be lajoskatona
14:38:47 <slaweq> are You ok with that?
14:39:04 <haleyb> ack from me
14:39:58 <slaweq> lajoskatona: if You couldn't do it next week, please let me know :)
14:40:11 <lajoskatona> Yes, I made notes o fit
14:40:14 <slaweq> ok, and that's all regarding bugs from my side
14:40:18 <slaweq> thx lajoskatona
14:40:32 <slaweq> any other bugs You want to talk about today?
14:40:46 <slaweq> or any other topics to discuss?
14:41:48 <slaweq> ok, if not I will give You 19 minutes back today
14:41:58 <slaweq> thx for attending the meeting and have a great week
14:42:00 <slaweq> o/
14:42:12 <lajoskatona> o/
14:42:13 <ralonsoh> bye
14:42:14 <slaweq> #endmeeting