| opendevreview | Ghanshyam proposed openstack/neutron master: DNM debugging designate job https://review.opendev.org/c/openstack/neutron/+/926945 | 04:57 |
|---|---|---|
| frickler | JayF: I think the usual term is Neutrinos although that sounds weird in a quantum physical context ;) and I like that idea although I'm just a strange quark around here ;) you'll likely want to create an RFE bug for more detailed discussion | 05:13 |
| *** elodilles is now known as elodilles_pto | 05:18 | |
| grami | Hi All, so I'm not 100% sure this is right I'm trying to add a new driver to networking-generic-switch could I ask if someone could review this please https://review.opendev.org/c/openstack/networking-generic-switch/+/926886 | 07:53 |
| grami | I also would like to cherry-pick it down to 2023.2 but I'm asking here first if this would be allowed? | 07:54 |
| lajoskatona1 | grami: Hi, networking-generic-switch is not under the governance of Neutron team, and I don't think there are people who can review (aka nobody has the technical background) your patch | 08:14 |
| lajoskatona1 | grami: I would try to reach out for the cores if anybody is still around: https://review.opendev.org/admin/groups/eaf58f67a6c1ac4246bec3197d3fbd5ea42e9b5b,members | 08:15 |
| grami | thanks for the quick response :) I'll do that | 08:44 |
| frickler | grami: iiuc the repo belongs to ironic, so you could also try asking in their channel | 09:09 |
| JayF | Yes, please send ngs folks our way. It is exceedingly maintained | 13:12 |
| *** joa_ is now known as joa | 13:29 | |
| lajoskatona1 | ykarel: Hi, perhaps you remember issue with issue like " Multiple possible networks found....", I can't find any trace of it. | 13:42 |
| lajoskatona1 | ykarel: for novaclient they run into such an issue: https://bugs.launchpad.net/python-novaclient/+bug/2077168 | 13:43 |
| mlavalle | lajoskatona1: most likely, ykarel is not on today. It is the quarterly "re-charge day" in RedHat-land | 13:57 |
| haleyb | i wonder how many we'll get for the drivers meeting then | 14:00 |
| mlavalle | yeap | 14:01 |
| joa | Hello, I'm here for it, at least | 14:01 |
| lajoskatona1 | o/ | 14:01 |
| haleyb | #startmeeting neutron_drivers | 14:01 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:01 |
| haleyb | Ping list: ykarel, mlavalle, mtomaska, slaweq, obondarev, tobias-urdin, lajoskatona, amotoki, haleyb, ralonsoh | 14:01 |
| mlavalle | \o | 14:01 |
| lajoskatona1 | mlavalle: ahh, I missed his name from m irc clients active list | 14:01 |
| lajoskatona1 | thanks | 14:02 |
| 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 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2075955 is the only thing on the agenda today | 14:03 |
| * mlavalle has a hard stop at 40 munutes after de hour | 14:03 | |
| joa | Sure :) | 14:03 |
| haleyb | mlavalle: ack, i'm a hard stop at :30 so you'll make it :) | 14:04 |
| 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 |
| mlavalle | haleyb, lajoskatona1: while we wait, can I get reviews for https://review.opendev.org/c/openstack/neutron/+/917800 | 14:05 |
| mlavalle | I added it to the priority list with +1 | 14:06 |
| mlavalle | no need to review now, just when you have some time | 14:06 |
| haleyb | put it on my list, thanks | 14:06 |
| lajoskatona1 | mlavalle: sure, I started to check the priority list anyway :-) | 14:07 |
| mlavalle | thanks guys | 14:07 |
| 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 |
| joa | Sure. | 14:08 |
| 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 |
| mlavalle | good decision | 14:09 |
| 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 |
| 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:10 |
| 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 |
| joa | the issue with that is that it enables communicating between the VMs through that service network, which we want to prevent. | 14:11 |
| joa | Which brings us to the current "hoped for" design: | 14:12 |
| 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 |
| 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:13 |
| 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:14 |
| joa | annd that's it for the intro. Ask away any precision you think might help :) | 14:15 |
| mlavalle | does it have to be two separate rfe's? or could we merge them together? | 14:15 |
| 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 |
| 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 |
| joa | with the help of slaweq on the RFE | 14:16 |
| joa | for the record, the other RFE is linked in the one we are discussing | 14:17 |
| mlavalle | would network security network bindings only allowed on shared networks or any kind of network? | 14:17 |
| mlavalle | I understand that for shared networks, tenenats wou;dn't be able to change security at the port level | 14:18 |
| 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:19 |
| lajoskatona1 | good point | 14:20 |
| joa | which is where the policy comes in, to provide the "lock" mechanism we need in our specific situation | 14:20 |
| mlavalle | ahh, I get it now | 14:20 |
| mlavalle | the lock is acomplished at the policy level for shared networks in your use case | 14:21 |
| 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:21 |
| mlavalle | yeah, slaweq knows a thing or two about policies | 14:22 |
| 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:22 |
| mlavalle | yeap | 14:23 |
| 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:24 |
| haleyb | i had a long day yesterday and brain is still 'off' | 14:25 |
| haleyb | the "Prevent Each VM on this network from seeing each other" is about the openstack tenant network(s) | 14:25 |
| 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 |
| 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:26 |
| 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:27 |
| 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 |
| 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 |
| lajoskatona1 | +1 | 14:29 |
| haleyb | yes, or even a picture :) we will just need to have the larger team present to approve anything | 14:30 |
| lajoskatona1 | yeah network bound sec-group sounds great, but I can imagine some skeletons under the years of code :-) | 14:30 |
| 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 |
| joa | MHhh I'm an adept of mermaid for visualisations, I'm guessing launchpad does not render it ? :D | 14:31 |
| joa | (in which case I'll join the generated pngs) | 14:31 |
| haleyb | i would be ok with you creating a spec to further explain some details raised here | 14:31 |
| haleyb | even ascii art is sometimes useful, or it will make sense in an hour :) | 14:31 |
| lajoskatona1 | joa: for specs we also use ascii art :-) | 14:32 |
| * mlavalle 's last spec included an ascii art diagram. so it works | 14:32 | |
| haleyb | i have another meeting i have to run to unfortunately | 14:32 |
| lajoskatona1 | or you can attach png to your text (https://opendev.org/openstack/neutron-specs/src/branch/master/images ) | 14:32 |
| mlavalle | don't forget to close the meeting haleyb | 14:33 |
| haleyb | joa: can you create a spec for this so we can discuss at a future meeting? | 14:33 |
| haleyb | it's ok if im a little late, can sneak in | 14:33 |
| joa | Sure, will do. end of next week probably | 14:33 |
| mlavalle | joa: thanks for the proposal. good stuff in my opinion | 14:33 |
| lajoskatona1 | thanks for it | 14:33 |
| haleyb | there is a neutron-specs repo | 14:33 |
| haleyb | i do think it would be useful | 14:33 |
| haleyb | alright, thanks for coming every and thanks for the discussion | 14:34 |
| mlavalle | I guess it is cross pollination from a group with a different experience implementing an IaaS platform | 14:34 |
| haleyb | yes, glad to see new users and use cases | 14:34 |
| lajoskatona1 | joa: here you can check example specs: https://review.opendev.org/q/project:openstack/neutron-specs | 14:34 |
| mlavalle | \o have a nice weekend y'all | 14:35 |
| haleyb | #endmeeting | 14:35 |
| opendevmeet | Meeting ended Fri Aug 23 14:35:54 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:35 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-08-23-14.01.html | 14:35 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-08-23-14.01.txt | 14:35 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-08-23-14.01.log.html | 14:35 |
| lajoskatona1 | o/ | 14:35 |
| haleyb | bye for now | 14:36 |
| joa | thanks everyone :) | 14:36 |
| opendevreview | Merged openstack/networking-sfc master: Fix _delete_ports_flowrules_by_id so that it expects only one port_id https://review.opendev.org/c/openstack/networking-sfc/+/926892 | 15:43 |
| opendevreview | Ghanshyam proposed openstack/neutron master: DNM debugging designate job https://review.opendev.org/c/openstack/neutron/+/926945 | 18:58 |
| cid | Hello people! | 20:16 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!