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