15:00:13 #startmeeting ironic 15:00:13 Meeting started Mon Oct 16 15:00:13 2023 UTC and is due to finish in 60 minutes. The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:13 The meeting name has been set to 'ironic' 15:00:15 o/ 15:00:18 o/ 15:00:21 o/ 15:00:40 Welcome to the Ironic meeting! A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. 15:00:47 #topic Announcements / Reminder 15:00:53 #info Standing reminder to review patches tagged ironic-week-prio and to hashtag any patches ready for review with ironic-week-prio: https://tinyurl.com/ironic-weekly-prio-dash 15:01:31 #topic Action items from previous meeting 15:01:35 I need to carry this over 15:02:00 #action JayF to backport ngs_save fix for networking_generic_swtich, cut a bugfix-version (not branch) release of it 15:02:09 sorry about that, it fell off my radar 15:02:20 #topic Caracal Release schedule 15:02:27 #link https://releases.openstack.org/caracal/schedule.html 15:02:34 Take note, we have a release schedule. 15:02:39 Any related commentary or discussion? 15:03:16 nothing from me 15:03:27 o/ 15:03:33 #topic October PTG 15:03:45 #info Topics/schedule have been aligned for PTG, please review 15:03:52 #link https://etherpad.opendev.org/p/ironic-ptg-october-2023 15:04:08 As always, there is some flexibility, please review and make noise if any proposed thing is ahardship. 15:04:17 Any related commentary or discussion on PTG? 15:05:01 nothing on my end 15:05:01 moving on. 15:05:05 #topic Ironic CI Status 15:05:11 Anything of note about Ironic CI? 15:06:04 Last week the cirros mirror went offline, it was down for ~4-6 hours, I think on Thursday. Rechecks may be needed but I may have already done them on the open changes from that time window 15:06:09 * TheJulia doesn't remember anymore 15:06:39 Aight. In general it's the quiet time so I'm not surprised the only report is a hard-break. 15:06:43 #topic RFE Review 15:06:45 One topic here 15:06:52 #link https://review.opendev.org/c/openstack/ironic-specs/+/896474 15:06:56 httpboot support 15:07:02 Please take note of the spec and review it 15:07:19 I will add it to my queue but probably will not be a +2 on it unless absolutely neccessary due to the lack of personal experience with redfish gear 15:07:22 If anyone has questions, please feel free to ping me 15:08:04 Also, FWIW, we have an ilo version which basically does the exact same thing as prior art, it is not mentioned, but it uses the httpboot bmc interface 15:08:15 oh, neat 15:08:34 I don't have access to ilo hardware for my work, fwiw, either, even though my downstream uses it 15:08:55 Thanks for proposing that spec. 15:08:57 #topic Open Discussion. 15:09:24 I'm going to note, this is a bit of a plug but we've got 50 minutes, I feel OK doing it :P 15:09:37 I'll be presenting at SeaGL on Nov 4, on Trust in an Open Source Community https://osem.seagl.org/conferences/seagl2023/program/proposals/984 15:09:52 I believe it'll be simulcast or rebroadcast digitally for those not in the area, if you're interested. 15:10:05 tks for sharing JayF =) 15:10:15 nice 15:11:06 Anything else for open discussion? 15:11:14 Do we have anything we need to discuss in advance of the ptg next week? 15:11:26 Just thinking, it is next week 15:11:58 I was hoping folks would look at the etherpad after the meeting and maybe that would induce conversation as needed 15:12:26 you and I went over it sync last week to get it scheduled 15:12:36 so I think mostly action lies on others now to do prework :) 15:12:40 I have more TC-PTG prework to do, too 15:13:07 It is also the week before the PTG, most of us need a little mental downtime plus time for administrative tasks 15:13:18 so, mileage will vary this week. 15:13:18 ++ 15:13:28 I have one if you want: Don't know if you remumber but I ask few weeks ago if you already work on Disk encryption. Seems that it was not the case, so we move on checking how we could integrate SED disks encryption with ironic, barbican etc. We will try to make a POC 15:13:32 I personally have had a lot of pulls on that cord as well the last two or three weeks 15:13:37 dtantsur: so I'm thinking of completely ripping glean out. Any objections? 15:13:54 It's not enough information for me to object or not :) 15:13:56 dtantsur: still supporting the case though, just not using external tools/logic to do parsing 15:14:12 drannou: so, is there hardware-assistance in the encrpytion or what? 15:14:13 If you suggest to rewrite it ourselves.. I'll ask WHY 15:14:44 drannou: would be interesting to see a writeup -- mailing list or RFE bug is OK if you're not spec-ready yet, about what you have in mind for on disk/orchestration 15:14:49 dtantsur: eh, we don't need to do *everything* it does, just a small portion of stuff 15:15:00 for a very short transient time, turns out to be very little code, really 15:15:22 TheJulia: I think pretty much everything it does is networking. 15:15:39 rip out glean in what context? 15:15:43 networking for long term consumption, we're in a ramdisk :) 15:15:50 virtual media boot handling/parsing of config-2 15:15:52 The very goal of supporting several different networking backends is quite hard. Let alone testing that in the CI. 15:15:54 ack 15:16:17 dtantsur: not if we're using the standard interface to make runtime changes 15:16:26 TheJulia: there are *at least* two of them 15:16:33 there's a standard, cross-distro network interface? 15:16:34 NM and systemd-network 15:16:37 iproute2 should be available 15:16:44 mmm 15:16:55 that won't do everything network-data can specify 15:16:58 e.g. bonding with vlans 15:17:07 we don't configure bonding 15:17:13 JayF: Yes, Drives like NVME support offloaded encryption: the device itself will manage it, on elec power on the disk is encrypted, waiting for the key. The idea would be to boot on IPA and let the IPA unlock the disk, and soft reboot on the disk 15:17:13 we can do it 15:17:18 and vlans was simple 15:17:20 And using low-level tools behind the NM back is a risky approach 15:17:27 okay, if someone were to do it manually, yes, they could articulate bonding 15:17:41 wdym manually? it's a part of network data. 15:18:01 I'm thinking in the fully integrated case, we bind ports individually afaik 15:18:14 so manually would be someone populating network_data and have no neutron 15:18:38 Which is what Steve Hardy is doing with Metal3 nowadays :) 15:18:40 The alternative is add additional backends to glean so we can test it in CI 15:18:57 (tinycore) 15:19:14 Or test with a real IPA image 15:19:25 can't due to rax 15:19:54 Can we ask the Infra to not schedule us there? I feel like we're going too far to solve RAX issues already... 15:19:56 or we rip out the fallback logic and just risk performance being a bigger issue 15:20:11 that's what I was about to ask, dtantsur 15:20:19 we have nested virt flavors. They can and do fail we ask people willing to use them to work with the cloud when that happens to figure it out as we are unable to debug for you 15:20:28 they are also in limited clouds so may go away 15:20:31 but haven't yet 15:22:03 I can always go deal with trying to write a glean backend for tinycore, but.. I dunno since there is fear over nested virt availability. We opt into nested virt where available 15:22:33 drannou: as long as there's an open standard for it, I don't see why we'd be in opposition to it. That being said; barbican is not a super active openstack project to be blunt, so that's the only piece that makes me nervous is taking a dep there. 15:22:34 A glean backend for tinycore is better than rewriting the whole Glean ourselves IMO 15:23:14 It is not the whole of glean, but if we're super fearful of just making runtime changes, then I can abandon the path I'm on 15:23:22 JayF: Yes I completely agree, but we would just use barbican for what it is : a secured key store 15:23:35 TheJulia: 80% of Glean is already too much Glean :) 15:23:56 drannou: if I was implementing it in Ironic; given the standalone-use-cases of Ironic, and especially that it's deployed in e.g. metal3, I'd probably suggest that key store be made into an interface in Ironic so it can be pluggable 15:24:49 There was work a few years ago to do on-boot encryption and plug that into a remote keystore 15:24:52 drannou: but I think it's obvious this is a feature that 'fits' Ironic; just write it up in an RFE and add it to "RFE Review" on meeting agenda (likely meeting next week is cencelled for PTG) 15:25:03 .... CoreOS had it turned on for a short while. 15:25:05 drannou: if we need more details, at that RFE review we might ask you to write a spec 15:25:11 hmm 15:25:12 I'm trying to remember what it was called 15:25:37 I'm going to close the meeting; we've sorta devolved into general chat at this point 15:26:26 #endmeeting