14:00:30 #startmeeting neutron_drivers 14:00:30 Meeting started Fri Sep 6 14:00:30 2024 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:30 The meeting name has been set to 'neutron_drivers' 14:00:42 Ping list: ykarel, mlavalle, mtomaska, slaweq, obondarev, tobias-urdin, lajoskatona, amotoki, haleyb, ralonsoh 14:00:43 \o 14:00:52 hi 14:00:52 hello 14:01:00 o/ 14:01:02 o/ 14:01:08 o/ 14:01:38 like last week, i have a hard stop in :30, but i only see two things on agenda for today 14:01:39 o/ 14:02:11 #link https://bugs.launchpad.net/neutron/+bug/2075955 14:02:27 this was from joa but i see ralonsoh had a comment on the spec 14:02:42 #link https://review.opendev.org/c/openstack/neutron-specs/+/927520 14:02:52 https://review.opendev.org/c/openstack/neutron-specs/+/927520/comments/d17f91e8_d7ac009c 14:03:04 just an fyi that we didn't approve the rfe but asked for the spec to get more detail 14:04:08 so what I commented in the review, and this is something that could be tested by the submitter, is that the spec scope can be achieved right now 14:04:49 but, of course, that is something the LP bug submitter should consider and comment 14:05:06 maybe there is a limitation that I didn't see 14:05:32 I wanted to at least better understand the proposal, with operational implications. Fwiw, we're currently having something based on zed, which means the feature is not available out of the box for us anyways to test, and would require some backporting first . 14:05:56 what feature? 14:05:59 RBAC? 14:06:16 https://review.opendev.org/c/openstack/neutron/+/883246 you mean 14:06:19 No, the patch linked in the comment, which was recently merged 14:06:20 yes 14:06:42 let's be clear on this: this feature will be implemented in master 14:07:02 yes, for sure. If usable, I'll have to backport it in our internal forks . 14:07:22 (along with all the related shenanigans for the cli and whatnot to work) 14:07:23 and, btw, you don't need as an admin to create the port 14:07:45 the non-admin user can create the port. And this non-admin user port will receive the default SG 14:08:02 and this user cannot modify the SG on the port, so you are enforcing the SG rules 14:08:11 (you==admin) 14:08:26 yes, that's already what I'm doing. To be frank, what the spec covers is something we're trying to POC internally at the moment, by lack of better alternative so far. 14:08:54 we agree that to prevent modifying SG on the port, we'll require a patch to allow policy control on port/SG bindings ? 14:09:05 in any case, and because you are testing that, I'll reply to the question of the gerrit comment (I didn't check it) 14:09:14 this is done 14:09:16 (which is already part of a second RFE, linked in the first) 14:09:27 you can define that a non-admin user cannot modify a port SG 14:09:33 oh ? might have forgotten to check on master then 14:09:40 and by default, the default SG cannot be modify by a non-admin user 14:09:51 it wasn't the case in zed, and I took some time to find out how to tweak that 14:09:56 the default SG belongs to a project and only the admin can modify it 14:10:14 those api policies are there for very long time already 14:10:55 About the default SG, I understand that your proposal is to change that default, to allow the network stream we need for our project. But then it'd be applied to all networks, right ? 14:11:16 a network belongs to a project 14:11:25 by default we don't have policies for sg field in the port 14:11:26 actually several networks can belong to a single project 14:11:31 it was for sure 14:11:32 slaweq: In zed, the `enforce_policy` flag on the sg extensions to control create_port:securitygroups and update_port:securitygroup was not set. 14:11:46 each port created on these networks, will receive the project default SG 14:11:58 you can create custom policies in policy.yaml file always 14:12:03 and should be respected 14:12:03 you can create custom policies 14:12:20 ralonsoh: Sure, but we want to configure that specific service network as an admin, then share/external the network providing access to the service with specific projects 14:12:32 it would be something like: "update_port:security_groups: rule:admin_only" if I'm not mistaken 14:13:09 yes, but was not available/supported in zed. maybe it has been added meanwhile though, in which case I only need to backport/replicate the behavior in our old version, until we upgrade. 14:14:01 then please move to a newer version. If you implement this RFE you are proposing, you won't have it in zed 14:14:11 you'll have the same problem 14:14:17 ralonsoh: I'm unsure how you perceive the "service network" I'm attempting to describe, but I don't really think it'd be a good idea to change the default for a whole project, as it might have multiple networks, that shoudl ahve the original defaults instead 14:15:06 then please describe, in Neutron terms, what "service network" is for you 14:15:11 ralonsoh: I'm aware that implementing it will mean backporting for zed anyways, which is not a big issue in itself. What we want is to diverge as little as possible from upstream in the long run 14:16:33 So, we need a shared/external network, defined by the administrator, that provides access to a service which is not managed by Openstack. The reason we're doing it this way, is that we want to be able to setup the network so that we can only share it to specific projects (not all), and to make it as easy as possible to "enable" access to the service by simply adding the network to the VMs requiring 14:16:39 it. 14:18:10 again, that is doable now: one project creates the shared network with a set of specific RBACs to other projects 14:18:24 and then the ports created on this network will have the same default SG 14:18:44 Also, we want to prevent VMs attached to this network from talking to each other: thus the restriction on adding SGs/updating SGs on the port. 14:19:10 Yes, we're already using rbac + policy to handle the individual sharing and preventing updates to the SG 14:19:29 the thing is: How do you offer the "default" for the port, without affecting the rest of the projects/networks/ports ? 14:19:33 So is the difference here between a "project default SG", which applies to all ports on all the project networks, and a "network default SG" which only applies to ports on a single network, over-riding the project default SG? 14:20:05 the default SG is per project, the project that created the shared network 14:20:11 haleyb: yes, that's how I see it. Of course, given how I was describing it in the spec, is slightly more flexible thatn a simple "network default sg" 14:20:47 ralonsoh: understood, i'm just trying to see what the ask is and if it's already doable today 14:21:05 ralonsoh: which is why I didn't delve into the idea of modifying the default SG. I only want that for these networks that would expose a service to some projects/VMs 14:21:27 (and of course, if we have more than one, each should have their own settings) 14:21:39 again: create a single project per shared network 14:21:56 ralonsoh: oh, right that's one way 14:21:57 joa do your tenants who owns vms connected to that "shared" network have also other vms which needs to use own, different SGs? 14:22:09 the default SG will apply only to each shared network port 14:22:10 so, I'd need to create as many "empty" projects as the number of networks that I need different defaults for ? 14:22:22 why not? 14:22:37 slaweq: Hypothetically, yes. 14:23:04 ralonsoh: ok that makes things clearer, I understand your point now, I missed the idea of a project per network 14:23:15 so if you will forbid updating SGs for regular users, it will affect all the vms/ports which they have 14:23:35 and they will not be able to set/update SGs for any of their ports 14:23:47 is that ok for you? 14:23:54 slaweq: I've fiddled with it, and found the right syntax to specify specific network ids 14:24:18 so that I can create the networks, go update the policies (tbh, that's a pain, but policies don't seem to be much for dynamism at the moment), and it'd be fine 14:24:56 it'd look like this (quite verbose, but seemed to work during my tests): 14:24:59 "custom_service_network": "'%%NETWORK_ID%%':%(network_id)s" 14:25:01 ahh, so you have policies with rules which contains some specific network_ids in the rules? 14:25:02 "create_port:security_groups": "rule:admin_or_network_owner or (role:member and project_id:%(project_id)s and not rule:custom_service_network)" 14:25:05 "update_port:security_groups": "rule:admin_or_network_owner or (role:member and project_id:%(project_id)s and not rule:custom_service_network)" 14:25:16 yes, starting from your feedback on the other RFE 14:25:57 so with that if you as an admin will set SG rule for such port you will have what You need, right? 14:26:46 probably, in which case ralonsoh cleared up what I did not understand originally, and we may be able to do without what I offered initially. Needs to be tested and validated though 14:26:58 (we're also struggling with OVN at the moment, lacking a network-savvy expert :D) 14:27:50 and in such case we may not need this RFE to be implemented at all to address Your use case so we may not want to do it, right? 14:28:03 so I think we can wait for feedback on this RFE and discuss it once we have it 14:28:16 ++ 14:28:22 slaweq: Yes, to be confirmed. Ralonsoh: agreed. 14:28:36 note that i'll be away for the next two weeks, so don't be in a hurry to hear from me x) 14:28:50 joa: so can you investigate more based on all the great comments above :) and update the bug/spec with any notes? 14:29:17 * haleyb thinks that was just agreed to while he was typing 14:29:19 the bug sure, but how should I update the spec ? with my corrected understanding and that I'll test before closing/resuming work ? 14:29:56 joa: if you can get it to work in the current (master) code and don't need the spec you can just abandon it 14:30:12 sure 14:30:36 if not we can discuss further 14:30:49 Just to double check, Do I need the patch linked in the spec's discussion ? 14:31:14 (I feel like I don't ?) 14:32:00 #link https://review.opendev.org/c/openstack/neutron/+/883246 14:32:02 that one? 14:32:08 yes 14:32:53 i think you do as that defines the default SG objects 14:33:11 But I can edit it on each project though, right ? 14:33:16 that was merged in 2023.2 btw 14:33:45 i'll let slaweq answer that :) 14:33:51 I means, it's a bit more manual in the setup, but I fail to see the need in itself, if I can edit the Default SG on a per-projet basis. 14:34:40 with this you as admin can define in neutron what SG rules will be added to every new SG created by users 14:35:14 so if you want to make sure that every new project will have same rules in their SGs, you should use this APIs from that patch 14:35:39 without that set of rules created automatically was always the same and hardcoded in neutron 14:35:56 ok. This was not a concern though, current default behavior so far is ok for us. Only modifying the default SG for those specific network/projects pair was important to us. 14:36:49 Alright, I'll try and pass the baton to someone internally, and update the RFE/Spec with our findings when I get back :) 14:37:13 ok, lets move on to other topic in agenda for today 14:37:17 #link https://bugs.launchpad.net/neutron/+bug/2078661 14:37:23 ralonsoh: that was the one you added 14:37:33 very quick because is trivial, but there is an API change 14:37:45 the flag propagate_uplink_status can be defined in a port during the creation 14:37:51 (that is for ML2/SR-IOV only) 14:37:58 I want to make is updatable, that's all 14:38:17 https://review.opendev.org/c/openstack/neutron-lib/+/927820/3/neutron_lib/api/definitions/uplink_status_propagation_updatable.py#30 14:38:29 that also implies a change in the SRIOV agent, receiving this change 14:38:58 any question? 14:39:05 lgtm +1 14:39:07 ralonsoh: ack. and that was going to be my second question - the sriov agent will need a change since it has work to do when updating the flag, correct? 14:39:27 I think (99% sure) that will work as is now 14:39:33 but I'll check it, of course 14:39:45 sounds reasonable for me 14:39:48 ralonsoh: ack 14:39:51 and straighforward 14:39:57 so +1 14:39:57 +1 14:39:58 +1 from me 14:40:00 +1 14:40:03 thanks folks 14:40:12 I have an on-demand topic 14:40:15 very quick one 14:40:20 https://review.opendev.org/c/openstack/neutron/+/926725 14:40:39 we said that in Antelope, we would start enforcing the quota 14:40:47 not enforcing, sorry 14:41:03 checking the quota before setting it, like any other project 14:41:21 now we do like --force by default 14:41:29 I'm removing it in this patch 14:41:46 (there is a warning message added 2 years ago) 14:42:01 what i'm removing here: https://review.opendev.org/c/openstack/neutron/+/926725/4/neutron/extensions/quotasv2.py 14:42:24 so this is not for voting, just for consideration and review, because is a significant change 14:42:31 thank you for reading me 14:43:05 thanks ralonsoh 14:43:32 thanks, will keep an eye on review 14:43:36 thanks! 14:43:39 thanks for the heads up 14:44:07 any other topics? 14:44:51 ok, thanks for attending everyone and for the good discussion. have a nice weekend! 14:44:55 #endmeeting