| rpittau | good morning ironic! o/ | 06:38 |
|---|---|---|
| AmarachiOrdor[m] | Good morning! | 06:38 |
| freemanboss[m] | Good morning ironic | 07:56 |
| Ayo[m] | Good morning everyone | 08:02 |
| queensly[m] | Good morning | 08:34 |
| abongale | Good morning ironic! | 09:04 |
| opendevreview | Satoshi Shirosaka proposed openstack/ironic master: Add shared image support https://review.opendev.org/c/openstack/ironic/+/947115 | 12:49 |
| TheJulia | Good morning | 13:22 |
| cardoe | morning Ironic... if someone wants to throw a +W across the https://review.opendev.org/c/openstack/networking-baremetal/+/945818 series that'll get pre-commit goal done for our repos. | 13:28 |
| cardoe | It's a fairly boring one. Just copy / pasta of the stuff we put in the other repos. | 13:28 |
| TheJulia | I'll try to remember to take a look once I open up gerrit for the morning | 13:29 |
| opendevreview | Abhishek Bongale proposed openstack/ironic-tempest-plugin master: fix: fail fast on deploy failure in Anaconda jobs https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/946886 | 13:37 |
| opendevreview | Merged openstack/networking-baremetal master: fix spelling mistakes https://review.opendev.org/c/openstack/networking-baremetal/+/945818 | 14:55 |
| rpittau | #startmeeting ironic | 15:00 |
| opendevmeet | Meeting started Mon Apr 14 15:00:08 2025 UTC and is due to finish in 60 minutes. The chair is rpittau. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'ironic' | 15:00 |
| rpittau | Hello everyone! | 15:00 |
| rpittau | Welcome to our weekly meeting! | 15:00 |
| rpittau | The meeting agenda can be found here: | 15:00 |
| rpittau | https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_April_14.2C_2025 | 15:00 |
| TheJulia | o/ | 15:00 |
| * TheJulia wonders if folks are just out of spoons from PTG week last week | 15:01 | |
| rpittau | same :D | 15:01 |
| TheJulia | I do wonder, we didn't figure out who is going to send a summary email. Would it make sense to draft something up today and send it? | 15:02 |
| TheJulia | (I know some folks also indicated they were taking some PTO this week.) | 15:02 |
| JayF | I'm out sick today. Can send summary email tomorrow if needed | 15:05 |
| TheJulia | I guess I'll spend some time today starting a summary email. I only really missed the deep into eventlet stuff if someone can help backfill any agreements to the summary | 15:06 |
| rpittau | we don't have a lot of people around today, may just close the meeting at this point | 15:08 |
| kubajj | o/ | 15:08 |
| TheJulia | ++ | 15:09 |
| rpittau | alright let's end it | 15:09 |
| rpittau | #endmeeting | 15:09 |
| opendevmeet | Meeting ended Mon Apr 14 15:09:35 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:09 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2025/ironic.2025-04-14-15.00.html | 15:09 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2025/ironic.2025-04-14-15.00.txt | 15:09 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2025/ironic.2025-04-14-15.00.log.html | 15:09 |
| TheJulia | I've started a summary at the bottom of the etherpad: https://etherpad.opendev.org/p/ironic-ptg-april-2025 | 15:09 |
| rpittau | TheJulia: ack, thanks, I'll try to review it tomorrow before EoD if you don't send it before | 15:11 |
| TheJulia | ack, thanks | 15:11 |
| cardoe | Apologies for missing the meeting. I might have bad touched some ceph and had to fix things. | 15:51 |
| TheJulia | Could use some help around https://etherpad.opendev.org/p/ironic-ptg-april-2025#L768 specifically eventlet and the hardware notifications stuffs | 16:36 |
| TheJulia | cardoe: ^ | 16:36 |
| TheJulia | Okay, I've got *everything* written up from last week *aside* from eventlet and hardware notifications | 17:45 |
| cardoe | Well... now what was I going to do today before I whoopsied/ | 20:02 |
| TheJulia | at least moopsie didn't visit! | 20:35 |
| * TheJulia plays video, realizes a moopsie walking sounds like wet sneakers on a polished floor | 20:41 | |
| rm_work[m] | Thoughts on having ironic boot UKI images? | 20:53 |
| rm_work[m] | Has there been discussion on that I could maybe catch up on? | 20:53 |
| TheJulia | I think a fundimental requirement for a UKI image is secure boot key management unless the ramdisk artifact which is embedded is embeeeded and signed by the kernel signature, so kind of a higher level challenge. To answer the direct question, yes there has been discussion, nobody has acted upon it because some of that dependency logic is required and it has, at least, thus far seemed disjointed enough given the existing | 20:56 |
| TheJulia | signing requirements that maybe distributors are not ready to do $thing. I know the last time I went into deep discussion with some of the folks driving that, they also semi-acknowledge (they, being UKI folks), that it would be problematic in a network boot or community context without independent key management and artifact signing, and minimally we've had to get them to make concessions in regards to kernel command line | 20:56 |
| TheJulia | arguments | 20:56 |
| rm_work[m] | Interesting, ok. Yeah, args are a problem right? Because it breaks the signing or something? I've been peripherally following it internally, supposedly folks here have boots working with some patching, but yeah we have a secure-boot story handled and it would entirely likely not be the same type of implementation everywhere | 20:59 |
| TheJulia | rm_work[m]: so, yeah, in the original UKI model, think everything is a laptop | 21:06 |
| TheJulia | And surely you have static volume name to boot to | 21:06 |
| TheJulia | and so you can measure the *entire* set of arguments | 21:07 |
| TheJulia | meaning the entire kernel command line in the UKI | 21:07 |
| TheJulia | The initial designs didn't account for that and we had to convince them that was a mistake | 21:07 |
| rm_work[m] | yeah, doesn't work as well in dynamic systems | 21:07 |
| TheJulia | (doesn't work well with server class gear in general where you may need to tune behavior based upon workload) | 21:07 |
| TheJulia | (or to make devices appear.... or other fun cases) | 21:08 |
| TheJulia | So, they re-evaluated and made exceptions, the big challenge is sitll sort of stages beyond it. Ultimately, if its in a disk image we're deploying, we won't notice. However, if you want to UKI IPA, that is a whole other matter and may be on a more painful path in general because the key management needs to be in place because you have to sign to change arguments with things like "hey, go boot from this url!" | 21:09 |
| TheJulia | or "here is your IPA endpoint" | 21:09 |
| rm_work[m] | yeah... and that does appear to be what we're doing (UKI IPA) | 21:10 |
| TheJulia | I think the happy path we kind of reached consensus on was virtual media based because then you could have IPA in your ramdisk and still boot with a UKI, just not ipa in the ramdisk file | 21:10 |
| TheJulia | explicitly network booting would require some way to inject stuff into nvram. others might remember more offhand. | 21:11 |
| TheJulia | Totally not difficult hurdles if you control multiple aspects and signing abilities or have a MOK or other key embedded | 21:11 |
| rm_work[m] | I'll see what it is looking like when we're a bit further along, people seem hopeful at the moment that it'll work, and I'm kinda just following along and hoping to keep things in sync with upstream | 21:11 |
| TheJulia | yeah, its is definitely not the cure-all many think it is | 21:12 |
| TheJulia | less so in anything dynamic | 21:12 |
| rm_work[m] | I personally feel like secure-boot is a bit overkill for our environment and that there are about 10 other places that would be a weaker link security-wise, but I am also not a security SME so I will leave them to it | 21:13 |
| TheJulia | That being said, wearing my RH hat, I don't think we are really expecting folks to want to use them in any dynamic case because of those challenges right now | 21:13 |
| rm_work[m] | I'm just allergic to major downstream patching and am starting to feel really itchy | 21:14 |
| TheJulia | yeah, understandably | 21:14 |
| rm_work[m] | glad to have your thoughts on it, thanks. I'm sure i'll follow up again in a while. | 21:14 |
| TheJulia | our downstream product folks basically told us to not rush into UKIs, espescially after we brought glaringly obvious issue around kernel command line parameters | 21:15 |
| TheJulia | (a lot easier to convince folks when you have a pile of cases where $vendor $equipment required $option to work) | 21:16 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!