opendevreview | Aleksandr Chudinov proposed openstack/neutron master: [OVN] Update lsp host id when cr port is updated with chassis https://review.opendev.org/c/openstack/neutron/+/931632 | 06:17 |
---|---|---|
opendevreview | Rodolfo Alonso proposed openstack/neutron master: DNM - Test "neutron-ovn-tempest-ipv6-only-ovs*" with WSGI https://review.opendev.org/c/openstack/neutron/+/932601 | 06:43 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add Neutron API eventlet experimental jobs https://review.opendev.org/c/openstack/neutron/+/931012 | 06:52 |
opendevreview | Merged openstack/neutron-tempest-plugin master: Stop running 2023.1 (Antelope) jobs in check/gate https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/932527 | 09:32 |
opendevreview | Merged openstack/neutron master: [OVN] Remove maintenance method ``check_port_has_address_scope`` https://review.opendev.org/c/openstack/neutron/+/932676 | 09:57 |
frickler | slaweq: sorry for offtopic ping, do you know something about the credentials for tobiko rtd? https://zuul.opendev.org/t/openstack/build/19f70a8342a846df894b062f39ccae3e | 11:56 |
ralonsoh | hello all, the meeting now will take place in https://meetpad.opendev.org/oct2024-ptg-eventlet-removal | 13:00 |
slaweq | frickler I will check it tomorrow morning | 13:29 |
slaweq | I'm in the eventlet removal session now | 13:30 |
ralonsoh | haleyb, so we'll start at 1500UTC | 14:21 |
mlavalle | haleyb: the eventlet session seems to be over. Do we meet in 39 minutes is tne Neutron room? | 14:22 |
haleyb | let's start at 1500UTC with ironic topic | 14:23 |
mlavalle | haleyb: ack | 14:24 |
lajoskatona | +1 | 14:29 |
*** gthiemon1e is now known as gthiemonge | 14:58 | |
ihrachys | cardoe: hey! | 16:04 |
cardoe | hello :) | 16:04 |
ihrachys | ultimately I think you can't get around SOME kind of negotiation between net and openstack admins over who uses what. the FORM of this negotiation - whether you have to restart neutron every time you want to deprovision a subset of VNIs, whether you can migrate an existing neutron network to a different VNI before it, whether you have API for both - can alleviate some pain | 16:06 |
ihrachys | though. | 16:06 |
ihrachys | in a way, "reservation" of *unused* VNIs is already present - what ralonsoh mentioned about you being able to create a fake network with the desired reserved VNI and then never use it in openstack. It's not beautiful but will work. | 16:08 |
ihrachys | the migration part is not possible though - though AFAIU from what Rodolfo said, there's a patch for that | 16:08 |
ralonsoh | we can now change a network VNI but there are some limitations (I need to find the patch). The reservation model can be used too | 16:08 |
ihrachys | also obv "create a fake network" scales bad if you have to take out a whole range of VNIs - you'd have to create a network per VNI | 16:09 |
ralonsoh | the VNI API is another alternative (that must check the current VNIO usage) | 16:09 |
ihrachys | ideally the VNI API would operate over range objects, not an object per vni | 16:09 |
ralonsoh | yes, create a network to reserve the VNI could be expensive | 16:09 |
ralonsoh | ihrachys, yes but we store the reservations in a table, one register per VNI | 16:10 |
ralonsoh | although we can handle them in the API in ranges | 16:10 |
ralonsoh | the patches that implemented the segmentation ID change: https://review.opendev.org/q/topic:%22bug/1806052%22 | 16:13 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Exit fast checking the external network default https://review.opendev.org/c/openstack/neutron/+/933132 | 16:46 |
cardoe | sorry. I was in another session and wasn't following along. | 17:48 |
cardoe | ihrachys: absolutely need some kind of negotiation between net and openstack admins. The point is that the net admins keep a source of truth that's fully API driven/available. So today the approach seems hack-y. update neutron.conf files and restart things. or create a bunch of fake networks. | 17:51 |
ihrachys | cardoe: I think a RFE to add api to reserve (ranges of) vnis dynamically will be well received | 17:56 |
cardoe | I've been trying to see how others have solved this. John mentioned he queries his source of truth and makes ansible inventory files. https://scs.community/ forked network-generic-switch and added callouts to NetBox. There's another project called Yaook Cloud which wrote their own type_vxlan.py. | 17:58 |
cardoe | https://opendev.org/x/networking-arista/src/branch/master/networking_arista/ml2/type_drivers/type_arista_vlan.py they wrote their own type_vlan.py and query them | 17:59 |
cardoe | We've explored doing our own type_vxlan.py as well but the only places I can see to call stuff are in a blocking location and I don't feel like that's correct. | 18:01 |
cardoe | I'll definitely work on the RFE. | 18:01 |
cardoe | What I want to do is create something that's acceptable to upstream instead of being another fork or custom hack. | 18:02 |
cardoe | Cause if upstream is aware of the use-case and understands it, it's less likely to be broken in the future. | 18:02 |
frickler | cardoe: that makes me curious, do you have some pointer to the scs and yaook forks? | 18:49 |
cardoe | I only pulled it out of yaook's container | 18:56 |
opendevreview | Merged openstack/neutron master: [OVN] Remove maintenance method ``check_for_mcast_flood_reports`` https://review.opendev.org/c/openstack/neutron/+/932677 | 22:06 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!