14:01:21 <haleyb> #startmeeting neutron_drivers 14:01:21 <opendevmeet> Meeting started Fri Aug 23 14:01:21 2024 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:21 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:21 <opendevmeet> The meeting name has been set to 'neutron_drivers' 14:01:31 <haleyb> Ping list: ykarel, mlavalle, mtomaska, slaweq, obondarev, tobias-urdin, lajoskatona, amotoki, haleyb, ralonsoh 14:01:33 <mlavalle> \o 14:01:57 <lajoskatona1> mlavalle: ahh, I missed his name from m irc clients active list 14:02:00 <lajoskatona1> thanks 14:03:10 <haleyb> joa: hi, just waiting to see if we have enough to make quorom. even if we don't can still talk about your rfe 14:03:37 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2075955 is the only thing on the agenda today 14:03:42 * mlavalle has a hard stop at 40 munutes after de hour 14:03:51 <joa> Sure :) 14:04:33 <haleyb> mlavalle: ack, i'm a hard stop at :30 so you'll make it :) 14:05:40 <haleyb> alright, i didn't know it was a RH re-charge day, but we can at least discuss the rfe and ask any questions to put in the bug 14:05:51 <mlavalle> haleyb, lajoskatona1: while we wait, can I get reviews for https://review.opendev.org/c/openstack/neutron/+/917800 14:06:03 <mlavalle> I added it to the priority list with +1 14:06:30 <mlavalle> no need to review now, just when you have some time 14:06:37 <haleyb> put it on my list, thanks 14:07:16 <lajoskatona1> mlavalle: sure, I started to check the priority list anyway :-) 14:07:27 <mlavalle> thanks guys 14:08:20 <haleyb> joa: do you want to give a quick overview? if we can get some clarifications on any questions might be able to discuss and/or approve at a future meeting 14:08:27 <joa> Sure. 14:09:05 <joa> To give a bit of context, my company is slowly switching towards openstack to manage our infrastructure, from a homemade stack, tailored to the specific needs of our historical product. 14:09:17 <mlavalle> good decision 14:10:05 <joa> In there, we have a "service", exposed to most of our user's VMs, that we want to somehow fit into an openstack compliant model; but the said service has no equivalent whatsoever in openstack, so there's a bit of forceps involved. 14:10:52 <joa> Thus, our idea was to create a network model that represented the service on the Openstack side, and we'd custom-configure our hypervisors to provide whatever routing configurations we'd need, towards this service, unmanaged by openstack 14:11:32 <joa> Initially, we hoped to be able to provide an external network, shared with only specific customers/projects, taht would "expose" the service. 14:11:56 <joa> the issue with that is that it enables communicating between the VMs through that service network, which we want to prevent. 14:12:14 <joa> Which brings us to the current "hoped for" design: 14:13:37 <joa> 1. Our current RFE, which offers to associate Security-Groups with a network, making it an implied default set of rules for any port from that network 14:13:45 <joa> 2. I have another RFE opened about preventing a "user" that uses a shared network from associating SecurityGroups with the ports they manage. 14:14:25 <joa> we hopes that with both these changes, we'd be able to defined a default security group, opening the way only to our services ; and that the user projects would not be able to further open this specific network 14:15:10 <joa> annd that's it for the intro. Ask away any precision you think might help :) 14:15:23 <mlavalle> does it have to be two separate rfe's? or could we merge them together? 14:16:03 <joa> I don't mind either way, I thought these could be considered and addressed separately. For the other RFE, I've been playing with it, and it seems sufficient to add a `enforce_policy` on the securitygroup extensions of the ports. 14:16:33 <joa> (then I've found a way to express what I needed, to prevent users from creating/updating security grousp for ports of specific networks) 14:16:45 <joa> with the help of slaweq on the RFE 14:17:24 <joa> for the record, the other RFE is linked in the one we are discussing 14:17:48 <mlavalle> would network security network bindings only allowed on shared networks or any kind of network? 14:18:24 <mlavalle> I understand that for shared networks, tenenats wou;dn't be able to change security at the port level 14:19:24 <joa> I'm not very knowledgeable in the various use-cases that neutron oversees, but I personally see no conflicting reason that would warrant not doing so. The way I see it at the moment, is that the SG(s) on the network are automatically applied to all ports. But this should not prevent the user from adding additional SGs on their ports. Then the rules would be merged, form the port's POV 14:20:04 <lajoskatona1> good point 14:20:17 <joa> which is where the policy comes in, to provide the "lock" mechanism we need in our specific situation 14:20:44 <mlavalle> ahh, I get it now 14:21:19 <mlavalle> the lock is acomplished at the policy level for shared networks in your use case 14:21:52 <joa> yes, by using the specific network's ID, to only "lock" for specific "external services" networks that we, as the administrators, would provide "some" projects. 14:22:25 <mlavalle> yeah, slaweq knows a thing or two about policies 14:22:54 <joa> He did point me towards that, and I spent a bit of time trying to understand why it wouldn't work out of the box. Though, but good learning on the policy side. 14:23:10 <mlavalle> yeap 14:24:49 <haleyb> so i'm still trying to draw a picture in my head about what this looks like... you have an external network where you have hosts offering services; you want to add SG rules to allow Openstack tenants access to certain IPs on that network; and vice-versa? 14:25:01 <haleyb> i had a long day yesterday and brain is still 'off' 14:25:51 <haleyb> the "Prevent Each VM on this network from seeing each other" is about the openstack tenant network(s) 14:26:01 <lajoskatona1> I am not sure if we can ask for a spec before officially accepting the rfe, but I feel that some details should be added 14:26:51 <joa> ahah no worries. To be more specific, the service is hidden behind a VIP, for which, on our legacy infrastructure, we've setup custom routing. We want to be able to provide access to the "service network" only for some projects (through rbac), and make sure that this network _ONLY_ enables contacting the said service 14:27:43 <joa> and yes, we don't want the VMs to see each other from this network, in part because our product does not offer this feature by default, but also because we might share the network to multiple tenants, and don't want them to start communicating involuntarily with each other 14:29:05 <joa> lajoskatona1: I was unsure how to proceed for this, as it seemed like a design question that warranted discussion before we tried to formulate things more precisely. If the general idea seems OK for the neutron team, then I'll gladly work on properly formulating what we envision in a spec. 14:29:26 <mlavalle> In principle I personally think this proposal is worth exploring. In fact, I'm surprised it's taken all these years to bubble up. I agree with lajoskatona1 that a spec will help us to sort out the details 14:29:41 <lajoskatona1> +1 14:30:45 <haleyb> yes, or even a picture :) we will just need to have the larger team present to approve anything 14:30:52 <lajoskatona1> yeah network bound sec-group sounds great, but I can imagine some skeletons under the years of code :-) 14:31:02 <mlavalle> and I think the spec must differentiate clearly the overall design from the specific way you intend to use it in your case 14:31:09 <joa> MHhh I'm an adept of mermaid for visualisations, I'm guessing launchpad does not render it ? :D 14:31:26 <joa> (in which case I'll join the generated pngs) 14:31:32 <haleyb> i would be ok with you creating a spec to further explain some details raised here 14:31:56 <haleyb> even ascii art is sometimes useful, or it will make sense in an hour :) 14:32:06 <lajoskatona1> joa: for specs we also use ascii art :-) 14:32:37 * mlavalle 's last spec included an ascii art diagram. so it works 14:32:40 <haleyb> i have another meeting i have to run to unfortunately 14:32:56 <lajoskatona1> or you can attach png to your text (https://opendev.org/openstack/neutron-specs/src/branch/master/images ) 14:33:10 <mlavalle> don't forget to close the meeting haleyb 14:33:17 <haleyb> joa: can you create a spec for this so we can discuss at a future meeting? 14:33:32 <haleyb> it's ok if im a little late, can sneak in 14:33:36 <joa> Sure, will do. end of next week probably 14:33:45 <mlavalle> joa: thanks for the proposal. good stuff in my opinion 14:33:48 <lajoskatona1> thanks for it 14:33:50 <haleyb> there is a neutron-specs repo 14:33:57 <haleyb> i do think it would be useful 14:34:18 <haleyb> alright, thanks for coming every and thanks for the discussion 14:34:21 <mlavalle> I guess it is cross pollination from a group with a different experience implementing an IaaS platform 14:34:41 <haleyb> yes, glad to see new users and use cases 14:34:58 <lajoskatona1> joa: here you can check example specs: https://review.opendev.org/q/project:openstack/neutron-specs 14:35:50 <mlavalle> \o have a nice weekend y'all 14:35:54 <haleyb> #endmeeting