14:00:35 <lajoskatona> #startmeeting neutron_drivers
14:00:35 <opendevmeet> Meeting started Fri Jan 28 14:00:35 2022 UTC and is due to finish in 60 minutes.  The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:35 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:35 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:00:39 <lajoskatona> Hi
14:00:39 <mlavalle> o/
14:00:46 <ralonsoh> hello
14:00:58 <slaweq> hi
14:01:08 <yamamoto> hi
14:01:10 <obondarev_> hi
14:01:55 <lajoskatona> Hi yamamoto
14:02:14 <lajoskatona> Ok, let's start
14:02:31 <lajoskatona> We have no RFE for today, but 2 topics in the "on demand agenda"
14:02:57 <lajoskatona> 1 from me, and it is to go back to the question of neutron-fwaas maintenance
14:03:16 <lajoskatona> see discussion on #openstack-tc with gmann: https://meetings.opendev.org/irclogs/%23openstack-tc/%23openstack-tc.2022-01-24.log.html
14:04:16 <lajoskatona> TC would like to make simpler to have maintainers for fwaas (anything) if I understand well, and to avoid project renaming where possible
14:04:58 <lajoskatona> so the question is if Inspur can keep maintaining / developing current fwaas repo in openstack/neutron-fwaas
14:05:08 <mlavalle> why don't we go to my original proposal  in December to Inspur?
14:05:56 <mlavalle> we can have them go though the process of formally rehabilitating the project in the stadium and we have the tamplates to guide us?
14:05:57 <slaweq> mlavalle: can You remind what was it exactly?
14:06:21 <mlavalle> I proposed using the template to evaluate stadium projects
14:06:27 <lajoskatona> perhaps this was it: http://lists.openstack.org/pipermail/openstack-discuss/2021-December/026425.html
14:06:31 <lajoskatona> I mean the mail
14:07:30 <lajoskatona> more likely this mail: http://lists.openstack.org/pipermail/openstack-discuss/2021-December/026442.html sorry
14:07:41 <mlavalle> yes the latter one
14:08:04 <lajoskatona> thanks mlavalle
14:08:09 <mlavalle> they already agreed to follow that path
14:08:17 <opendevreview> Merged openstack/neutron-lib stable/train: Enforce policy for qos_policy_id attribute  https://review.opendev.org/c/openstack/neutron-lib/+/826225
14:08:56 <obondarev_> does it contradict with what gmann suggested?
14:09:00 <mlavalle> and if we follow that process, it will alleviate the concern of adding more workload to the core team, because there will be commitments on th side of Inspur
14:09:56 <lajoskatona> mlavalle: yes, I think this can work
14:10:11 <slaweq> ++ for that if it will be better to have it in stadium again, instead of moving it to x/
14:10:17 <obondarev_> +1
14:10:32 <lajoskatona> If there is no activity we have still the option to stop fwaas maintenance again
14:10:33 <mlavalle> obondarev_: a little bit, but I think that Inspur, if they really want to maintain the project, should have some skin in the game
14:10:51 <slaweq> and regarding question about if we want to have it in stadium or not: I personally am fine with having it in stadium if the inspur team will maintain it
14:11:12 <lajoskatona> +1
14:11:14 <mlavalle> yeah, as long as we have a commitment
14:11:21 <mlavalle> from Inspur
14:11:25 <slaweq> we can make some of their developers cores in the neutron-fwaas repo even so we will not need to do a lot there hopefully
14:11:28 <ralonsoh> one question: being in stadium means releasing every cycle, right?
14:11:30 <mlavalle> and we formalize that commitment in a doc
14:11:47 <ralonsoh> (a part from other requirements)
14:11:57 <slaweq> ralonsoh: usually yes, but that generally depends on the release model for the project IIIUC
14:12:00 <mlavalle> ralonsoh: yes
14:12:05 <ralonsoh> thanks
14:12:46 <ralonsoh> so +1 from me, good to see people collaborating on Neutron orbit
14:13:57 <mlavalle> and I think Inspur will have a better offering to their customers. They now can claim that the new FWaaS has the official recornition of being in the Stadium
14:13:58 <lajoskatona> +1 from me also
14:14:25 <mlavalle> they can claim that Saint Lajos has annointed the project :-)
14:14:42 <lajoskatona> :-)
14:14:52 <lajoskatona> not me but the team
14:14:58 <slaweq> +1 from me too
14:15:11 <obondarev_> +1
14:15:18 <mlavalle> +1
14:15:18 <yamamoto> +1
14:15:43 <lajoskatona> but I can send the mail about it, so my stamp will be on top ;)
14:15:51 <mlavalle> cool
14:15:59 <mlavalle> you got the idea
14:17:03 <lajoskatona> ok, next topic is from slaweq: https://bugs.launchpad.net/neutron/+bug/1959332
14:17:17 <slaweq> thx lajoskatona
14:17:29 <slaweq> everything is already described in the bug description
14:17:37 <slaweq> but I will quickly explain here too
14:18:12 <slaweq> basically, with new rbac policies and scopes enforcement, project_admin user can access everything but from one project only
14:18:21 <slaweq> there is no "super user" who can access everything
14:18:43 <slaweq> so basically there is no user which can do "openstack port list" and see ports used as router external gateway
14:19:08 <slaweq> with old defaults, project admin (admin) can see all resources so also such ports
14:19:42 <slaweq> If we look at code https://github.com/openstack/neutron/blob/d0fd4aa30adc883971bd4d87e0540523bded7a38/neutron/db/l3_db.py#L337 - it is done intentionally that this port don't belongs to any project
14:20:03 <ralonsoh> I was looking for this
14:20:06 <slaweq> and now the question is - if we want to have those ports visible in api somehow, and if yes, how to solve it :)
14:20:16 <ralonsoh> why is that?
14:20:25 <slaweq> why is what ralonsoh ?
14:20:40 <ralonsoh> to let the port without project
14:20:45 <ralonsoh> the GW port
14:20:59 <slaweq> According to the comment there, to not expose such ports for regular users
14:21:22 <ralonsoh> this is not a good reason with RBACs in place now
14:21:36 <slaweq> we could probably change it to belong to tenant and add policy rule so such ports would be available only for admin users
14:21:46 <lajoskatona> with new RBAC model whose project_id should be there?
14:22:03 <ralonsoh> for project admin/users yes
14:22:03 <slaweq> lajoskatona: IMO it should be same owner as of router
14:22:15 <mlavalle> yeah I think so
14:22:18 <lajoskatona> ok
14:22:29 <ralonsoh> I agree with the second alternative you propose: to assign the project ID
14:22:35 <mlavalle> me too
14:22:37 <ralonsoh> matching the router project ID
14:22:41 <mlavalle> is the cleanest
14:22:54 <ralonsoh> (of course, for sure that will have a ton of issue will see later)
14:23:03 <obondarev_> yeah, the one without "hardcode" word in description :)
14:23:08 <slaweq> and new policy rule to make such ports available only for the PROJECT_ADMIN by default, right?
14:23:17 <lajoskatona> that's sounds reasonable
14:23:21 <ralonsoh> yes
14:23:33 <slaweq> so operator will even be able to modify it if will want to expose such ports to users
14:23:36 <mlavalle> yeah, but that's probably the shake up that needs to happen as a consequence of implementing the new RBAC model OpenStack wide
14:23:47 <slaweq> sounds like step in good direction with new rbac
14:24:28 <slaweq> mlavalle: I think that there will be many such shake ups there :)
14:24:38 <slaweq> this is really huge change
14:24:38 <mlavalle> yeap, me too
14:25:19 <slaweq> ok, thx for Your opinions on this
14:25:23 <slaweq> I think I know what to do now
14:25:29 <mlavalle> btw, I think that we should not only fix this in Neutron, but also we should share the "incident" with the new RBAC czars leading this at the OpenStack weide level
14:25:36 <slaweq> so I will summarize this discussion in the Launchpad and will propose some patch
14:25:53 <mlavalle> they should see the consequences of their decisions
14:26:24 <mlavalle> maybe there is a learning in this for them too
14:26:28 <slaweq> mlavalle: sure, I will add people responsible by RBAC to the review of that patch and will explain it to them
14:27:12 <mlavalle> they might even have suggestions based on the impact they've seen in other projects
14:28:06 <slaweq> TBH I don't think so - this is probably something specific to neutron that resource which normally belongs to the project, don't belong to any project in some case
14:28:14 <lajoskatona> I see long discussions again for the PTG :-)
14:28:19 <mlavalle> lol
14:28:26 <slaweq> and it sounds for me like "hack/workaround" on our side :)
14:28:44 <mlavalle> cool
14:28:57 <slaweq> thx for Your feedback and suggestions on this
14:29:01 <slaweq> that was all from me
14:29:23 <lajoskatona> thanks for bringing it here and taking care of it
14:29:25 <mlavalle> thanks for bringing this up
14:30:19 <lajoskatona> If there's nothing more, we can close the meeting for today
14:30:26 <slaweq> ++
14:30:30 <mlavalle> nothing else from me
14:30:45 <lajoskatona> #endmeeting