| TheJulia | cardoe: I guess really ovn vs neutron might be part of it. | 01:08 |
|---|---|---|
| TheJulia | different triggers | 01:08 |
| TheJulia | hmmmm | 01:08 |
| TheJulia | clif: might have recovered, I've triggered a recheck on one of the jobs | 01:12 |
| clif | thank you | 01:12 |
| cardoe | TheJulia: oh man you are crushing it on those changes. | 01:24 |
| cardoe | I need to get caught up. | 01:25 |
| TheJulia | cardoe: I don’t have lldp data locally, but I’m sort of approaching things as “this should world, experimental, well backport bug fixes” for the vxlan stuffs | 01:54 |
| Continuity | TheJulia: im not sure it did to be honest, sorry been busy going live with a new customer. | 09:44 |
| Continuity | Also morning all | 09:44 |
| dtantsur | TheJulia: Nahian acked a follow-up | 12:01 |
| dtantsur | (Thinking aloud) Virtual media has its unique challenges when it comes to debugging a *FAIL state. Even if I don't power off the machine, the clean up code ejects the ISO, which on some machines has effect immediately, potentially rendering the operating system half-broken. | 13:23 |
| dtantsur | But if we don't eject on the path to *FAIL, when do we do it? | 13:24 |
| * dtantsur has been thinking about all this for more than a week and hopes that someone has brilliant insights | 13:24 | |
| TheJulia | Continuity: okay, no worries, I've been super busy | 14:02 |
| TheJulia | dtantsur: perhaps the answer is to leave the power on until exiting the fail state, or more so is the issue that the fail state exit back to available is automatic | 14:03 |
| dtantsur | TheJulia: it's not hard to leave power on, but the virtual media ISO is gone | 14:04 |
| TheJulia | move it to teardown of deploy fail, have a knob to leave leave it on and in that state | 14:05 |
| dtantsur | (I don't know if it's a big deal for the default IPA - I guess we don't access the ISO there after booting) | 14:06 |
| TheJulia | Ultimately, the vmedia should, ideally, still be rooted in ram, unless we're using the vmedia device as a persistent block device | 14:06 |
| TheJulia | if the power is still on, the ramdisk is usable/funcitonable | 14:06 |
| dtantsur | Well, CoreOS definitely uses its root file system from the ISO. Maybe it's a CoreOS problem.. | 14:06 |
| TheJulia | the other side of this problem is we shift security risk if someone leaves a node like hthat for months | 14:06 |
| dtantsur | yeah | 14:06 |
| TheJulia | but yeah, sounds like the way the coreos ramdisk is working is not really a ramdisk as much as a vmedia boot/root disk | 14:09 |
| TheJulia | which is weird, since they have the layered cpio file, maybe they intentionally pivot root? | 14:10 |
| dtantsur | Yeah, CoreOS' initramfs is not enough to really do anything | 14:11 |
| dtantsur | Basically, it only knows enough to find a rootfs on the ISO or download it from network | 14:11 |
| TheJulia | but its not unpacking it into ram, its using it directly it sounds? | 14:12 |
| TheJulia | this is sort of why we've always kept our parts and pieces in initramfs bits because there is no need to pivot there, it creates some of the same sort of headaches in fun ways, but nothing that cannot be overcome really | 14:14 |
| dtantsur | yeah, using directly (it's not really small) | 14:40 |
| TheJulia | ugh | 14:44 |
| TheJulia | cardoe: I've got claude working on fixing the notifications stuffs for neutron callbacks which should make event triggered model happier... hopefully. | 14:45 |
| TheJulia | I didn't catch it latched on to metrics style notifications instead as the model | 14:45 |
| TheJulia | well, did eventually. | 14:45 |
| opendevreview | Merged openstack/bifrost master: Remove url tags from README https://review.opendev.org/c/openstack/bifrost/+/974620 | 15:15 |
| cardoe | ooo very nice | 15:25 |
| opendevreview | Merged openstack/ironic-python-agent master: bootc install: Treat SELinux Permissive like Enforcing https://review.opendev.org/c/openstack/ironic-python-agent/+/972809 | 16:14 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic master: [DNM] Testing upgrade lock fw https://review.opendev.org/c/openstack/ironic/+/975300 | 16:25 |
| TheJulia | cardoe: that only works if your a direct plugin | 16:59 |
| TheJulia | cardoe: I'll just tighten the loop I guess. | 16:59 |
| opendevreview | Julia Kreger proposed openstack/networking-baremetal master: Trunk port reconciliation for L2VNI attachments https://review.opendev.org/c/openstack/networking-baremetal/+/974619 | 18:07 |
| TheJulia | cardoe: ^^^ - For your context, where my context is at is where ports/subports are created, I've not gone to the point of having actual metadata tied in, but I would strongly hope ovn's self capture of the data might just work, maybe. I'm sure there are bugs there but ones we're not going to flesh out without actually starting to get it into the paces of use | 18:09 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add ironic-networking network interface https://review.opendev.org/c/openstack/ironic/+/966470 | 19:30 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Add standalone networking service installation guide https://review.opendev.org/c/openstack/ironic/+/966471 | 19:30 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Improve exception handling in switch driver factory https://review.opendev.org/c/openstack/ironic/+/969852 | 19:30 |
| opendevreview | Allain Legacy proposed openstack/ironic master: Address remaining review comments for rpc methods https://review.opendev.org/c/openstack/ironic/+/971184 | 19:30 |
| opendevreview | Julia Kreger proposed openstack/networking-baremetal master: WIP: Fix for bug 1995078 https://review.opendev.org/c/openstack/networking-baremetal/+/975333 | 21:09 |
| TheJulia | Continuity: what about something sort of shaped like ^ | 21:09 |
| Continuity | :eyes: | 21:10 |
| Continuity | TheJulia: looks interesting, I'll get someone with some actual python skills to ahve a look over it next week. | 21:14 |
| Continuity | Would that be backportable to 2025.1 | 21:14 |
| TheJulia | maybe not immediately, but maybe, I've not tested it, I just pointed claude at the bug and was like "could we whip something up here where we take a model of reconciling and fixing?". As all AI assistants do, it showered me with love for the great idea and wrote me some code. | 21:15 |
| opendevreview | Julia Kreger proposed openstack/networking-baremetal master: Trunk port reconciliation for L2VNI attachments https://review.opendev.org/c/openstack/networking-baremetal/+/974619 | 21:34 |
| Continuity | Yeah I have a cron job doing something very similar at the moment:( | 21:42 |
| TheJulia | heh | 21:43 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: DNM - Claude generated mcasta range support https://review.opendev.org/c/openstack/networking-generic-switch/+/975339 | 21:44 |
| TheJulia | hjensas: hmmm | 21:48 |
| hjensas | TheJulia: I got curious, and asked what it would look like - and ended up spending too much time. | 21:50 |
| TheJulia | heh | 21:51 |
| TheJulia | it happens :) | 21:51 |
| TheJulia | my big worry is the eventual "I want to change this" disaster | 21:51 |
| hjensas | yes, it kind of is with a single address as well. But more manageable ... If this was something that was written to DB, like the VLAN ID for a network, it can't be changed after the fact. This should be the similar ideally. | 21:55 |
| TheJulia | dell os10 with vxlan is super problematic because you have to have to have an intermediary structure which is numbered per switch with a restricted range (1-65535). I do wonder if it might make sense to wire up some additional data storage somehow. | 22:04 |
| TheJulia | other conundrum, is the distributed nature | 22:05 |
| TheJulia | cardoe: you might be of interest w/r/t vxlan+cisco. | 22:15 |
| cardoe | hrm I'll have to take a look | 22:17 |
| TheJulia | Basic topic is BUM handing with multicast style configs | 22:20 |
| rm_work[m] | Random question for a friday afternoon: is the autodiscovery feature for ironic nodes actually worth using? like is it awesome and everyone uses it, or is it really niche? We DO have an inventory system where new hardware shows up, and right now we enroll them manually... but it might be cool to write a script to do that since I assume that's what it's for | 22:32 |
| rm_work[m] | actually I already have a script that reaches into our inventory system and generates an ironic enrollment YAML block for each new server... so it seems like it'd be trivial probably to convert that to a real script/plugin if i could find a good example | 22:33 |
| rm_work[m] | though maybe I misunderstand what this feature is for / does | 22:34 |
| cardoe | We do the same thing. auto discovery doesn't work cause there's too many gotchas. | 23:55 |
| cardoe | e.g. the BIOS setting for the media to boot from is disabled | 23:56 |
| cardoe | But you cannot alter the BIOS without booting IPA with Ironic | 23:56 |
| JayF | Not just that, but I think initial enrollment being a human process where people validate that, for instance, you got the RAM and disks you paid for physically, is a better way to do it. You have to have humans involved anyway to physically rack and stack the servers anyway. | 23:58 |
| JayF | And your vendor should be providing metadata to make enrolling your machines in ironic, at least far enough to get inspection going, is trivial | 23:58 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!