| janders | good morning Ironic o/ | 06:30 |
|---|---|---|
| opendevreview | David Nwosu proposed openstack/ironic master: Move configdrive tests to test_configdrive_utils https://review.opendev.org/c/openstack/ironic/+/965880 | 06:53 |
| opendevreview | David Nwosu proposed openstack/ironic master: Move configdrive tests to test_configdrive_utils https://review.opendev.org/c/openstack/ironic/+/965880 | 07:01 |
| hroy | good morning o/ | 07:09 |
| rpittau | good morning ironic! o/ | 07:56 |
| rpittau | TheJulia: ok, thanks, I will have a look today, I'm trying to understand what's going on with the dib jobs in https://review.opendev.org/c/openstack/bifrost/+/964404 | 07:58 |
| rpittau | also it looks like there is an issue with unit tests in ipa with python3.10 https://zuul.opendev.org/t/openstack/build/ccfd2145d8d44cc29dc2dc12e97d7629 | 07:58 |
| opendevreview | Verification of a change to openstack/ironic-python-agent master failed: Build and publish updated debian images https://review.opendev.org/c/openstack/ironic-python-agent/+/966513 | 08:18 |
| opendevreview | Jacob Anders proposed openstack/ironic master: [WIP] Add Redfish health status monitoring and synchronization https://review.opendev.org/c/openstack/ironic/+/966946 | 08:23 |
| opendevreview | Jacob Anders proposed openstack/ironic master: [WIP] Add Redfish health status monitoring and synchronization https://review.opendev.org/c/openstack/ironic/+/966946 | 08:33 |
| janders | ^^ that should fix backwards compatibility | 08:35 |
| opendevreview | Verification of a change to openstack/ironic-python-agent-builder master failed: Fix firmware cleanup - more. https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/966950 | 08:50 |
| opendevreview | Jacob Anders proposed openstack/python-ironicclient master: [WIP] Add support for node health status field https://review.opendev.org/c/openstack/python-ironicclient/+/966954 | 08:52 |
| opendevreview | Jacob Anders proposed openstack/ironic master: [WIP] Add Redfish health status monitoring and synchronization https://review.opendev.org/c/openstack/ironic/+/966946 | 09:37 |
| janders | ^ hopefully this has a chance of passing CI | 09:38 |
| opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent stable/2025.1: Test advertised ip reachability before assigning it https://review.opendev.org/c/openstack/ironic-python-agent/+/966776 | 10:51 |
| opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent master: Fix RuntimeError when stopping heartbeater in rescue mode https://review.opendev.org/c/openstack/ironic-python-agent/+/967006 | 11:03 |
| opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent master: Fix RuntimeError when stopping heartbeater in rescue mode https://review.opendev.org/c/openstack/ironic-python-agent/+/967006 | 11:06 |
| opendevreview | Merged openstack/ironic-python-agent master: Build and publish updated debian images https://review.opendev.org/c/openstack/ironic-python-agent/+/966513 | 12:09 |
| opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent master: Fix RuntimeError when stopping heartbeater in rescue mode https://review.opendev.org/c/openstack/ironic-python-agent/+/967006 | 12:26 |
| opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] Remove tinyipa support and switch to debian IPA https://review.opendev.org/c/openstack/bifrost/+/964404 | 12:30 |
| opendevreview | Merged openstack/ironic-python-agent unmaintained/2024.1: Update .gitreview for unmaintained/2024.1 https://review.opendev.org/c/openstack/ironic-python-agent/+/965713 | 13:28 |
| rpittau | uefi jobs look a little fubar in 2025.1 | 13:31 |
| opendevreview | Jacob Anders proposed openstack/ironic master: Add Redfish health status monitoring and synchronization https://review.opendev.org/c/openstack/ironic/+/966946 | 13:42 |
| opendevreview | Jacob Anders proposed openstack/python-ironicclient master: Add support for node health status field https://review.opendev.org/c/openstack/python-ironicclient/+/966954 | 13:43 |
| janders | ^^ folks, for those of you interested in basic redfish hardware monitoring we discussed in PTG, here's my initial, minimal implementation. Lab tested, works, I would welcome your feedback! (CC kubajj) | 13:44 |
| kubajj | janders: 🫡 | 13:44 |
| janders | my thinking is very much get to MVP ASAP, there's heaps more that could be done with this concept but probably it's best to start small and build upon that | 13:48 |
| rpittau | anyone can think of any reason why now we suddenly get "No space left on device" on uefi jobs in 2025.1 ? | 13:50 |
| rpittau | started happening yesterday | 13:50 |
| opendevreview | Riccardo Pittau proposed openstack/ironic stable/2025.1: [DNM] test CI stable/2025.1 https://review.opendev.org/c/openstack/ironic/+/967030 | 13:55 |
| opendevreview | Jacob Anders proposed openstack/python-ironicclient master: Add support for node health status field https://review.opendev.org/c/openstack/python-ironicclient/+/966954 | 13:59 |
| gibi | o/ we are proposing to decreate the defautl value of nova's sync_power_state_pool_size config option from 1000 to 5. This is used by the ironic virt driver. If you have any concerns about it the please add it to https://review.opendev.org/c/openstack/nova/+/966016 | 14:25 |
| lutimura | hey! does anyone know who/what is responsible for uploading the files available at https://tarballs.opendev.org/openstack/ironic-python-agent/tinyipa/files/? | 14:43 |
| TheJulia | lutimura: it was a automated job, we're no longer maintaining tinyipa files for a number of reasons. What causes you to raise the question? | 14:44 |
| lutimura | TheJulia: there's a job that failed with post_failure in openstacksdk (stable/2025.2): https://zuul.opendev.org/t/openstack/build/cfd53ddebf8b4c9db9e91a3f4f75124c | 14:46 |
| lutimura | apparently, it's looking for a file that doesn't exist there | 14:46 |
| lutimura | tinyipa-stable-2025.2.vmlinuz | 14:46 |
| opendevreview | Merged openstack/ironic-inspector unmaintained/2024.1: Update .gitreview for unmaintained/2024.1 https://review.opendev.org/c/openstack/ironic-inspector/+/965681 | 14:46 |
| TheJulia | gibi: Interesting. At a glance, I don't think I have any concern there. I think it ended up lockstepping through previously, but that is a much more sane pattern with eventlet going away :) | 14:49 |
| TheJulia | lutimura: okay, so we likely need to swap the job out | 14:49 |
| stephenfin | lutimura: I just came here to say the same thing :D | 14:52 |
| lutimura | TheJulia: oh, ok! | 14:54 |
| TheJulia | so, a few things going on | 14:54 |
| TheJulia | and I'm working on a patch | 14:54 |
| TheJulia | first off, the job was using tinyipa. Which is fine, but for the artifact to be built, a patch has to merge and all and I think we ended up removing the scripting as well, so there just wouldn't be a 2025.2 artifact... ever. So, the job config needs to be changed, and I'm working on that. | 14:55 |
| lutimura | stephenfin: hello there! :) | 14:56 |
| lutimura | TheJulia: in this case, the change would be to use a different ramdisk? i.e. https://opendev.org/openstack/openstacksdk/src/branch/master/zuul.d/functional-jobs.yaml#L268 | 14:57 |
| TheJulia | lutimura: change 967049 submitted to do just that | 14:58 |
| TheJulia | In other words, I removed the override and reset teh amount of memory | 14:58 |
| lutimura | TheJulia: oh, nice! thanks for that | 15:01 |
| cardoe | cid: any success? I did the sushy code base ages ago. | 15:07 |
| cardoe | cid: we just need to get over the fact that ruff is gonna re-format the code base. | 15:07 |
| cid | I have not actually gotten around to it yet. I guess i will JFDI now to see. | 15:08 |
| gibi | TheJulia: thanks | 15:08 |
| cid | One moment | 15:08 |
| cardoe | https://review.opendev.org/c/openstack/sushy/+/934916 was the compromise step. | 15:09 |
| cid | ++ | 15:10 |
| opendevreview | Verification of a change to openstack/ironic-lib unmaintained/2024.1 failed: Update .gitreview for unmaintained/2024.1 https://review.opendev.org/c/openstack/ironic-lib/+/965689 | 15:13 |
| stephenfin | cid: cardoe: JayF: (because I happened to check here at just the right time) In case you haven't seen it, I've done a lot of working on typing in various oslo and SDK projects. I've found the use of ruff (and black before it) essential, especially if you're working on things iteratively | 15:33 |
| stephenfin | a few other things of note | 15:34 |
| stephenfin | 1. the pre-commit hook approach isn't ideal because (a) mypy is slow and (b) it requires you to duplicate your dependencies in additional_dependencies. The latter is okay for oslo projects but idk how well it would scale for projects with more deps | 15:35 |
| opendevreview | Jacob Anders proposed openstack/ironic master: [WIP] Add Redfish health status monitoring and synchronization https://review.opendev.org/c/openstack/ironic/+/966946 | 15:35 |
| stephenfin | also, pre-commit doesn't have the requirement caching feature that tox 4 does, so we've hit issues where people behaviour differences across systems depending on how old their pre-commit env is | 15:36 |
| stephenfin | (tbc, we're still using it everywhere and I've yet to arrive at a better solution, but it's worth noting) | 15:37 |
| stephenfin | 2. if you're working on a library, you definitely want to take into account the Robustness Principle and be liberal in what you accept (collections.abc.Sequence over list or tuple if you need indexing: collections.abc.Iterable if not). It's a PITA to consume them otherwise. | 15:39 |
| opendevreview | Jacob Anders proposed openstack/python-ironicclient master: Add support for node health status field https://review.opendev.org/c/openstack/python-ironicclient/+/967055 | 15:39 |
| stephenfin | 3. ideally you don't want to set ignore_errors=True on tests since tests are a user of your code. You _will_ need to disable some of strict mode if using mocking and likely make liberal use of 'type: ignore' but I wouldn't disable it entirely. cliff is probably the best example of this that *I* have worked on recently | 15:40 |
| stephenfin | 4. lastly, type hints makes LSPs sooo much better to use: if there's something that's not easily hintable, I've erred towards redesigning it so I can benefit from the LSP goodness | 15:42 |
| stephenfin | load of unsolicited advice there, sorry 😅 I'd be *very* interested in seeing the result of your MonkeyType use. I've tried that tool (and a few others like it) previously and was never happy with the results, so it'd be good to see a case of it being used right | 15:43 |
| stephenfin | oh, one last one: https://github.com/zubanls/zuban is probably worth a look at. There are 3 other rust-based Python type checkers under active development right now (this, astral's ty and FB's pyrefly) but that one has a mypy compat mode that allows easy testing if you're already using mypy | 15:45 |
| stephenfin | *there are 3 rust-based | 15:46 |
| cid | stephenfin: | 15:49 |
| cid | Thanks for pointing those out. Actually, I'm trying out the ruff approach now. | 15:49 |
| cid | cardoe: the unsafe syntax upgrade fixe worked for me and fixed a bunch of things as well as break some unit tests. | 15:51 |
| cid | The stubgen -> monkeytype -> myright part, those I'm yet to get working | 15:51 |
| stephenfin | cid: Nice. Pro-tip: if you have two commits - one to disable a lot of the hacking checks and apply ruff, and another to re-enable just the hacking (H) checks and add ruff to pre-commit - then you can add the "apply ruff" commit to a .git-blame-ignore-revs file so git-blame is still useful | 15:52 |
| stephenfin | Also, I initially used to split ruff/black patches up into multiple patches based on different modules. It doesn't make reviewing any less tedious and you're better off doing it all at once and getting it merged asap | 15:53 |
| stephenfin | IMO | 15:53 |
| cid | ack'd | 15:54 |
| * cid will be stepping a way from the keyword for a while, but I think the ruff approach is promising. I will see if I can get a patch up by weekend. | 15:55 | |
| *** jizaymes_ is now known as jizaymes | 16:04 | |
| opendevreview | Jacob Anders proposed openstack/ironic master: Add hardware health monitoring via management interface https://review.opendev.org/c/openstack/ironic/+/966946 | 16:16 |
| opendevreview | Merged openstack/python-ironicclient unmaintained/2024.1: Update .gitreview for unmaintained/2024.1 https://review.opendev.org/c/openstack/python-ironicclient/+/965748 | 16:26 |
| opendevreview | Merged openstack/ironic-python-agent-builder unmaintained/2024.1: Update .gitreview for unmaintained/2024.1 https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/965704 | 16:32 |
| rpittau | so according to https://review.opendev.org/c/openstack/ironic/+/967030 the uefi job in 2025.1 is fubar, looks like some disk space issue, I incerased that to 5 GB and it's working except for ipv6, probably we're at limit, may need to go up to 6 or more | 16:52 |
| rpittau | I'll check tomorrow if no one beats me to it :) | 16:52 |
| cardoe | stephenfin: so you're saying ignore the slight difference between the openstack style for imports and what ruff does and just use tools? | 16:59 |
| stephenfin | oh, no, I haven't enabled the import ordering fixes | 17:00 |
| stephenfin | https://github.com/openstack/cliff/blob/master/pyproject.toml#L100-L101 | 17:01 |
| stephenfin | or https://github.com/openstack/python-manilaclient/blob/master/pyproject.toml#L209-L210 | 17:01 |
| TheJulia | rpittau: do you have a link to a log showing the failure your percieving that fixing? | 17:03 |
| dtantsur | "cdc_ncm 1-1:1.0 enp58s0f4u1: renamed from usb0" -- any idea what this device is? | 17:35 |
| dtantsur | 'HPE Virtual NIC (NCM)' | 17:38 |
| TheJulia | Odds are... It is the in-bound network interface from the BMC being offered to the host | 17:39 |
| TheJulia | (hint, they should disable these in the BMCs) | 17:40 |
| dtantsur | oh yeah | 17:41 |
| dtantsur | I also wonder if I should expand https://github.com/openshift/ironic-agent-image/pull/195/files | 17:42 |
| JayF | > [ 14.171303] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) | 17:43 |
| JayF | on a fresh devstack using a downloaded ramdisk | 17:43 |
| JayF | I wonder if we have a bad one published | 17:44 |
| * JayF looking in logs for direct link | 17:44 | |
| JayF | hah, VM_SPECS_RAM=2048 | 17:44 |
| JayF | is still in our default devstack setup | 17:44 |
| JayF | I suspect that works with ~nothing now? | 17:44 |
| TheJulia | oh, I increased that in the job | 17:44 |
| TheJulia | 2500 should work | 17:44 |
| JayF | it's not increased in the doc, I'll push that update and restart my build :-| | 17:45 |
| TheJulia | sorry | 17:45 |
| cardoe | TheJulia: you were asking how the pool of VLANs gets excluded on a specific leaf pair and https://review.opendev.org/c/openstack/ironic/+/964570 is the patch that we do that with | 17:48 |
| TheJulia | huh, what? | 17:48 |
| opendevreview | Jay Faulkner proposed openstack/ironic stable/2025.1: Update devstack guides to raise RAM requirement https://review.opendev.org/c/openstack/ironic/+/967083 | 17:49 |
| TheJulia | cardoe: I'm not entirely sure where that is coming from, my brain doesn't know the origination of the ask or answer and how it maps | 17:50 |
| cardoe | We create a neutron network segment range of type=vlan physical_network=<same-value-as-ironic-baremetal-port> and when the VLAN segment under the VXLAN is created it will use that network segment range for the possible VLAN | 17:51 |
| cardoe | Binding will fail if that segment doesn't have any available VLANs | 17:51 |
| TheJulia | for the vlan on the leaf right? | 17:53 |
| cardoe | yes | 17:54 |
| JayF | it looks like that ram is actaully 2750 in our jobs | 17:56 |
| TheJulia | JayF: Yeah, 2500 seems to be good since we made some firmware cleanups a few months back | 17:56 |
| cardoe | I'm happy to write a release note and we can backport that if you want. It's a new "feature". | 17:56 |
| * JayF bumped his local one to 4096 | 17:56 | |
| JayF | I have plenty of ram :) | 17:57 |
| opendevreview | Clif Houck proposed openstack/ironic master: Configuration file for Trait Based Networking https://review.opendev.org/c/openstack/ironic/+/962598 | 17:57 |
| opendevreview | Clif Houck proposed openstack/ironic master: Generate network plan based on trait based networking config https://review.opendev.org/c/openstack/ironic/+/964895 | 17:57 |
| opendevreview | Clif Houck proposed openstack/ironic master: Trait Based Networking Simulator https://review.opendev.org/c/openstack/ironic/+/966202 | 17:57 |
| TheJulia | cardoe: I'm guessing I'm missing the predicate of what direction your heading, because I think the purpose of the l2vni plugin is to facilitate that resource/data storage in neutron and ultimately something needs to then do the physical plumbing to the multicast (or unicast tunnel mes) of the physical nodes | 17:58 |
| opendevreview | Jay Faulkner proposed openstack/ironic stable/2025.1: Update devstack guides to raise RAM requirement https://review.opendev.org/c/openstack/ironic/+/967083 | 18:02 |
| cardoe | So the setup is "openstack network create --type vxlan .... network-bob" results in a Neutron network that is VXLAN and has a VNI. Then we create a subnet on that network. Then you'll do "openstack port create my-port --network network-bob ...." and it'll be a port on. that VXLAN network. | 18:03 |
| JayF | > | stable/2025.1 < A++ :( | 18:03 |
| opendevreview | Jay Faulkner proposed openstack/ironic master: Update devstack guides to raise RAM requirement https://review.opendev.org/c/openstack/ironic/+/967087 | 18:03 |
| cardoe | Now you either use nova to do "openstack server create ...." attaching to that network or you can do "openstack baremetal node vif attach <baremetal-port> my-port" | 18:04 |
| cardoe | That baremetal port is gonna send its traffic untagged to that switch port. | 18:05 |
| cardoe | n-g-s or not-n-g-s needs to connect to that switch and make it listen to the VNI and then bind that VNI to an un-used VLAN and then configure the port to use that VLAN as its native VLAN. | 18:06 |
| cardoe | so that vif attach is going to trigger the ML2 bind_port() first and then trigger update_port_postcommit() | 18:06 |
| * TheJulia reads more | 18:07 | |
| TheJulia | Yes, concur | 18:07 |
| cardoe | bind_port() in https://review.opendev.org/c/openstack/neutron/+/965053 sees that you are trying to attach a baremetal port to a VXLAN network in it's bind_port() and it says lulz that won't work. | 18:08 |
| cardoe | Now when Ironic triggered Neutron, it copied the baremetal port's local_link_connection info to the port object but with https://review.opendev.org/c/openstack/ironic/+/964570 it will also copy in the physical_network to the port. | 18:09 |
| cardoe | So https://review.opendev.org/c/openstack/neutron/+/965053 reads the physical_network value from the port and calls allocate_dynamic_segment(type=vlan, physical_network=<data-that-ironic-sent>) | 18:10 |
| TheJulia | okay | 18:12 |
| cardoe | ALL neutron networks have segments no matter what. So the network has a VXLAN segment always and https://review.opendev.org/c/openstack/neutron/+/965053 says "the VXLAN segment is bound at level 0 to my-port, I have created a dynamic VLAN segment at level 1 which is also bound to that port. Please pass this along to any other driver that might be interested in that." | 18:12 |
| cardoe | today n-g-s cares only about VLAN segments being bound on a port. When it sees that it reads the VLAN ID from the segment and tells the switch "hey this port is native VLAN X" | 18:14 |
| TheJulia | Yeah, I think the question starts to become who owns maintainance of the leaf switch vlan used for the translation. | 18:15 |
| cardoe | So with <patch-not-yet-written-cause-of-time-and-im-not-using-n-g-s> it will see that the VLAN segment its binding is a child to a VXLAN VNI and also write to the switch "hey you're listening on VNI Y and locally you're binding that to VLAN X" | 18:15 |
| cardoe | So in my case I'm allowed to use VLAN 2000-3000 by our network folk. | 18:16 |
| TheJulia | yeah, so I'm starting to re-write my vxlan spec doc to do two things: Help bring clarity to the latter, and it feels like we're going to need an intermediate service to facilitate the actual interconnect | 18:17 |
| cardoe | So I do for physnet in $(openstack baremetal port list | uniq physical_network); do openstack network segment create --physical_network $physnet --type vlan --minimum 2000 --maximum 3000; done | 18:17 |
| TheJulia | insomuch as on the VXLAN side, the standing switch fabric might be dynamic and most likely doing something like multicast vxlan or ebgp to spread the vnis around and we need to surface/attach the two. | 18:18 |
| cardoe | Absolutely. There's a whole VXLAN configuration side of n-g-s that would be that thing. | 18:19 |
| TheJulia | yup | 18:19 |
| cardoe | I'll write it but it'll be a bit hand-wavy cause I'm not using n-g-s | 18:20 |
| TheJulia | And ideally, that is *entirely* just "we already have the vni, do the vlan to vni attachment and then do physical port binding of the physical interfaces to the appropriate vlan | 18:20 |
| cardoe | Cause I don't actually touch the switches directly. | 18:20 |
| TheJulia | Yeah, indeed | 18:20 |
| cardoe | So this is where the Cisco ACI ML2 or the Juniper ML2 comes back to life a little bit. | 18:21 |
| cardoe | Cause those two make API calls to do those operations already. | 18:21 |
| TheJulia | sort of, but uniformity is varried | 18:21 |
| cardoe | So I've only got experience with the Cisco ACI ML2. But it only works with neutron type=vlan networks. And they have a separate DB patch you apply to neutron so that they capture this nesting data of the VXLAN and VLAN | 18:23 |
| cardoe | Your physical_network value in neutron is a numeric offset applied to the neutron VLAN ID to create the VNI ID | 18:24 |
| cardoe | I'm no longer working with Cisco ACI so haven't updated things. | 18:25 |
| cardoe | But it'd clean up their entire ML2 plugin drastically. | 18:26 |
| cardoe | Cause in update_port_postcommit() you'd walk each segment you're sent and if its a VXLAN you make the API call to bind it to the leaf pair and for the VLAN segment you attach it to the port and none of these hoops to calculate what the VNI is and blah. | 18:27 |
| cardoe | Then you change their create_network_postcommit() to use the actual VXLAN VNI from neutron instead of int(network.physical_network) + network.segmentation_id | 18:28 |
| TheJulia | That seems.. problematic | 18:28 |
| cardoe | And first time users won't be trying to debug their neutron to figure out why it just crashed with TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' | 18:29 |
| cardoe | So like if you wanna use VNI range 10000 to 14000 with their plugin. You do "openstack network segment range create --type vlan --physical_network 10000 --minimum 0 --maximum 4000" | 18:31 |
| TheJulia | Yeah, thats just awful | 18:31 |
| TheJulia | so, better forward way in your mind would be what? Because I'm thinking the vni needs to be known in advance and not necessarilly dynamically assigned that way, but still needs to be mapped. Perhaps a range is then thus needed | 18:32 |
| cardoe | Well this is where that DCIM integration comes in that we kinda touched on. | 18:33 |
| TheJulia | So, that is extending the requirements further and futher | 18:33 |
| cardoe | I doesn't have to though. | 18:33 |
| cardoe | Because today OpenStack hand waves that away. | 18:34 |
| TheJulia | Is there a simple state we can boil that down to if it is not an explicit mapping (or range) | 18:34 |
| cardoe | Thou must have network switches and have them configured such that n-g-s can login to them and control the ports. Your network switches must already have the cross-connects done such that VLAN traffic flows just fine. | 18:34 |
| TheJulia | That is today | 18:34 |
| TheJulia | where do we want to be *tomorrow* | 18:34 |
| cardoe | So the same statement applies Thou must have your fabric configured. | 18:35 |
| * TheJulia has thoughts here | 18:35 | |
| TheJulia | yes | 18:35 |
| TheJulia | agreed | 18:35 |
| cardoe | So the DCIM stuff is where you don't have that. | 18:35 |
| cardoe | So I'm happy to explain a tomorrow world | 18:36 |
| cardoe | Or we can stick to the Thou Shalt state. | 18:36 |
| TheJulia | I think the model and I'm going to be hand wavey here | 18:37 |
| cardoe | But using only OpenStack stuff today | 18:37 |
| TheJulia | awwww | 18:37 |
| TheJulia | Your starting to break my dream here ;) | 18:37 |
| cardoe | heh. oh no I wasn't limiting you. I'm saying I'll say this part. | 18:38 |
| cardoe | I want to setup a fabric of hardware assuming I have cabinets with hardware in them. 1. switches are configured with their cross-connects setup. 2. I have credentials for n-g-s to manage each switch. 3. I have an allowed VNI range 4. I have an allowed VLAN range on each leaf pair. | 18:40 |
| TheJulia | I think the model is we basically have FRR acting as a middle man to the fabric so we spread/gain VNI context from the fabric. We listen for port bindings and we use the host running FRR (or hosts, preferably hosts) to act as the "translators". What that means is we, can't take VXLAN from compute nodes and just map/wire it up. We take *whatever* is on the VM/Neutron virtual network side, and we physically attach it to an | 18:40 |
| TheJulia | interface, and then hook that to the VNI on the FRR side, or create as necessary, and have that act as the middle ground proxy. In the end, Neutron doesn't need to be particularly aware or could be doing *whatever*, but we're wiring it across and allow the port binding to continue on the physical network fabric side using the assigned free (or in a range) vni | 18:40 |
| cardoe | openstack network segment range create --type vxlan --minimum vni-lower --maximum vni-max | 18:41 |
| TheJulia | and vlan, based upon *known* config of mapping available vlans inside the physical network | 18:41 |
| cardoe | for cabinet in $(list of cabinets); do openstack network segment range --type vlan --physical-network $cabinet --minimum vlan-lower --maximum vlan-max; done | 18:41 |
| TheJulia | I realize I'm slightly hand waving on the neutron/attachment side, but the deeper I get into it the more it feels like we're going to need a connection proxy of sorts | 18:41 |
| * TheJulia wonders if we scared vsaienko away ;) | 18:42 | |
| TheJulia | Yeah, fundimentally you could do that as well, I'm not super convinced *inside* neutron is the right location. I could go with it, but given all of the resistance and constraints, I'm starting to have some doubt there | 18:42 |
| cardoe | Yeah so today my ML2's create_network_postcommit() pokes FRR to advertise the VNI | 18:43 |
| TheJulia | cool | 18:43 |
| cardoe | https://github.com/metallb/frr-k8s | 18:44 |
| cardoe | It depends how far you wanna go | 18:46 |
| cardoe | That's only necessary for baremetal <-> KVM interaction | 18:47 |
| cardoe | no physical switches have needed that | 18:49 |
| TheJulia | oh yeah, I was already digging into FRR's capabilities yesterday | 18:50 |
| cardoe | With physical networks and baremetal servers only I can do this with those 2 patches linked above and a forth coming n-g-s patch | 18:56 |
| cardoe | My test env switches are already mine so I can have n-g-s touch them directly so I'll test it. | 18:56 |
| TheJulia | well, you have frr at play in the middle too it sounds like | 19:01 |
| cardoe | It's some tinkering right now. | 19:08 |
| TheJulia | I *think* the near impossible state is to mesh the compute nodes directly together since we really need the baremetal ports to start at networking nodes. | 19:16 |
| cardoe | So that's where toreanderson's piece lives on the compute nodes to do that meshing. Apparently the work that Jakub is doing for OVN BGP will make that more native. | 19:20 |
| cardoe | So the question is https://review.opendev.org/c/openstack/ironic/+/964570 what do you wanna do with that TheJulia ? | 19:31 |
| TheJulia | cardoe: I'd think merge it | 19:50 |
| TheJulia | so, it sounds like the focus is l3 evpn traffic flows, but apparently in ovn 2025.09 work was done for l2 evpn, except for the auto-learning of Type-2 (MAC+IP) evpn routes, which leaves me thinking we'll still need a translator matrix, but I have a name of another person at RH to reach out to who actually did the OVN work itself | 19:52 |
| opendevreview | Merged openstack/ironic-python-agent-builder master: Fix firmware cleanup - more. https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/966950 | 19:54 |
| TheJulia | Looks like OVN added other_config:dynamic-routing-vni to the logical switches which can be defined in OVN | 19:54 |
| -opendevstatus- NOTICE: The OpenDev team will be restarting Gerrit at approximately 2130 UTC in order to pick up the latest 3.10 bugfix release. | 20:31 | |
| cardoe | hmm interesting I'll have to check that out | 20:50 |
| cardoe | TheJulia, JayF, clif: would ya like to have an ad-hoc network fun times at 11am eastern tomorrow? | 20:54 |
| JayF | I can't do Friday mornings. | 21:30 |
| JayF | There's a reason I suggested today :) | 21:30 |
| JayF | tomorrow it'd have to be after 11am PT | 21:30 |
| clif | I should be able to do tomorrow afternoon if that works, otherwise monday also works for most of the day | 22:17 |
| *** dmellado9 is now known as dmellado | 22:18 | |
| opendevreview | Clif Houck proposed openstack/ironic master: Trait Based Networking Filter Expression Parsing and Base Models https://review.opendev.org/c/openstack/ironic/+/961498 | 22:26 |
| opendevreview | Clif Houck proposed openstack/ironic master: Configuration file for Trait Based Networking https://review.opendev.org/c/openstack/ironic/+/962598 | 22:26 |
| opendevreview | Clif Houck proposed openstack/ironic master: Generate network plan based on trait based networking config https://review.opendev.org/c/openstack/ironic/+/964895 | 22:26 |
| opendevreview | Clif Houck proposed openstack/ironic master: Trait Based Networking Simulator https://review.opendev.org/c/openstack/ironic/+/966202 | 22:26 |
| cardoe | Tomorrow afternoon is fine | 22:27 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!