15:00:07 #startmeeting ironic 15:00:07 Meeting started Mon Oct 30 15:00:07 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:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:07 The meeting name has been set to 'ironic' 15:00:13 Hey guess what; another meeting! 15:00:20 #topic Announcements/Reminder 15:00:21 o/ 15:00:29 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:00:40 o/ 15:00:48 #topic Review action items from previous meeting 15:01:04 #info JayF to backport ngs_save fix for networking_generic_swtich, cut a bugfix-version (not branch) release of it 15:01:13 going to be honest, don't remember if I did this, checking 15:01:13 o/ 15:01:27 you did 15:01:32 did it land? 15:01:39 just need to update based on the reivew 15:01:45 JayF: re ironic docs: I think I replied too, or maybe not :P 15:01:57 rpittau: ack, will add you to the meeting, I thought I missed someone 15:02:15 rpittau: my IRC "highlights channel" is unreadable after the last week, for some reason :D 15:02:23 iurygregory: I'll follow up on it 15:02:29 #topic Caracal release Schedule 15:02:33 :D 15:02:35 #link https://releases.openstack.org/caracal/schedule.html 15:02:55 it's there, take note, I'll call out the next milestone in future meetings but didn't do the prework for that today :) 15:03:10 I doubt there's action for us to take this week for release in October :D 15:03:14 #topic PTG Review 15:03:24 #link https://etherpad.opendev.org/p/ironic-ptg-october-2023 15:03:47 Alright, this is what I was trying to get to. We have a lot of action items from this. The longer term ones/workstreams are going into workstream doc, obviously 15:03:59 I wanna track any "JFDI" level items here 15:04:41 Actually; brakes and reverse: I don't want to take this for granted; thank you all for participating in vPTG last week 15:05:23 Going to start plugging some action items in here. Just because they're here doesn't mean they're due next week, just means I wanted to have them written somewhere other than the etherpad :) 15:05:31 #action JayF to Merge something to metalsmith readme/release notes to announce it is going into maintenance mode before it's next release 15:05:36 #undo 15:05:36 Removing item from minutes: #action JayF to Merge something to metalsmith readme/release notes to announce it is going into maintenance mode before it's next release 15:05:41 #action JayF [from PTG] Merge something to metalsmith readme/release notes to announce it is going into maintenance mode before it's next release 15:06:19 the other item around metalsmith will be tracked in the workstreams doc (I think dtantsur still owes an RFE for that; but there's no need to track it) 15:06:48 #action JayF [from PTG] Submit something to contributor docs, drafting a bug deputy role which triages bugs, checks periodic job status, and runs a bug jam meeting 15:06:58 #action JayF [from PTG] Setup IPA-builder in launchpad 15:07:33 ... do we have periodics? 15:07:43 all stable jobs run in periodics aiui 15:08:01 #action masghar [from PTG] provide feedback about specific gaps in documentation, fix if small, provide feedback if more sizable 15:08:10 .. That doesn't seem right, but it could still be done and not obvious with the config 15:08:27 masghar: I'll note, something that's even two or three lines by next week will be super useful; no need to stress over details if you're short on time. 15:08:36 TheJulia: either way; I'll dig as part of doign it 15:09:18 #action JayF [from PTG] Update any written vendor driver policy to indicate it's about coordination/communication, not as much 3rd party CI now. 15:09:24 that's tuesday LOL 15:09:52 #action JayF [from PTG] email list about IntelIPMIManagement driver usage 15:10:25 I don't see explicit actions bolded out of OVN/Redfish, TheJulia were there any? 15:10:43 looks like maybe just make 3 bugs are the only actions there? 15:10:55 JayF: None from OVN, it was more information/context setting 15:10:59 Redfish, Let me glance again 15:11:11 I think that's all the "small" actions AFAICT 15:11:21 everything else is large enough to need a bug or to be in a workstream 15:11:51 to set expectation, nonzero chance many of these will push until next week, but they'll 100% get done early-early next week 15:11:59 One is too early, network port toggling, and the boot record is JFDI the bug and figure out if we can do a secondary purge 15:12:49 Oh, there is one other action not to drop 15:12:55 Also, RFE for boot status, but nothing major really 15:12:57 small building blocks 15:13:11 #action JayF Book a meeting with stakeholders; TheJulia JayF and johnthetubaguy minimum, on Nova driver bug fixing/hunting 15:13:42 If anyone wants in on that, please ask; only reason we didn't PTG it was so we'd be fresher :) 15:14:29 Alright, anything else as follow-up to PTG before we move on? 15:14:50 #topic Review Ironic CI Status 15:15:08 I haven't seen any random failures, but I don't think we've been hammering the gate the last week by any stretch :D 15:16:16 haven't seen any p[articular recurring or worrying failure since a while 15:16:42 #topic RFE Review 15:16:45 there's one up for review 15:16:50 #link https://bugs.launchpad.net/ironic/+bug/2040236 15:17:19 Reading this RFE, I'm not sure I want to approve it as written. 15:17:50 The bug itself implies that it might add the config and only implement it for iRMC 15:18:04 if we add a config under `[conductor]` to set that path, it needs to be respected throughout 15:18:32 and it raises questions around stuff like, should we have separate settings for CA to verify other services connecting in? What about verifying BMCs? Or agents? Shoudl that path be respected if auto tls is on? 15:18:43 Just seems like there's enough edges there that an RFE bug might not be sufficient. 15:18:44 WDYT? 15:18:57 so... I guess I'm conflicted 15:19:07 because verify_ca is supposed to take a path out of the box 15:19:11 If it was like, [irmc]irmc_default_verify_ca_path 15:19:54 I guess I don't understand *why* from the lp bug 15:20:23 I'll comment in there, saying we were unable to approve because the scope and the "why" is unclear 15:20:26 Why do we need a second level default 15:20:46 since it's a bit complicated for the reporter to be online (due to Timezone) we probably need to raise the questions we have in the RFE 15:20:51 I won't tag it needs-spec yet, but I'll ask for it to be updated before being readded to meeting agenda 15:20:54 of course :) 15:20:57 and take async 15:20:58 looks like they also want to add it as a node field 15:21:04 which is... semi-problematic 15:21:21 Yeah, we can't have that as a per-node override. 15:21:21 not insurmountable, but yeah, better understanding of need is needed 15:22:08 There *is* a case where you might need a different CA package to talk to to the BMC, and that could be reasonable 15:22:27 but then that requires you know internal details like location of files on disk and set/get that via an API 15:22:31 [agent]verify_ca exists 15:22:34 so does [ilo]verify_ca 15:22:42 but nothing condcuctor-wide 15:23:47 yeah, this is driver level for speaking with the remote BMC 15:23:47 OK; so I think we need to needs-spec this then, if it's node level 15:23:52 because we need to be very explicit about how we RBAC a setting to change the verify_ca settings per node 15:24:14 Do you think that's overkill? 15:24:27 RBAC wies, it would just need to be adminy user 15:24:30 wise 15:24:42 From a what is in the field wise, it really can't be a file path 15:25:01 which makes this further challenging 15:25:07 Why not? You'd expect the deployment tooling to do key management. 15:25:27 Think user not having filesystem access to the remote server where Ironic is running 15:25:35 they don't *actually* know where the files are for that CA 15:25:38 I don't see another path other than full auto_tls style or something like an API integration with a key manager 15:25:47 best they can supply, realistically, is a URL 15:25:54 oh, CA is not a private key 15:25:57 it's a public key 15:26:00 correct 15:26:04 but they want to provide paths 15:26:10 but URL is still not ideal, because you can't trust that value is the same 15:26:12 * drannou has done his homework, when you want to speak about RFE #2039676 15:26:14 this needs to be specced. 15:26:34 JayF: yeah, basically it does need to be written up in a more verbose form 15:26:51 I get their basic intention after skimming the openshift enhancement doc 15:27:16 and after you looked at the config, we just need to find a sensible path forward 15:28:36 commented, tagged needs-spec 15:28:40 drannou: that was not on the agenda 15:28:45 drannou: usually we prefer those be on the agenda first 15:28:56 but I'm curious :) 15:29:03 no problem, we can discuss about it when you want 15:29:42 You're going to likely get the same answer from me, after looking over the RFE (I've read it already in the past) 15:29:49 a feature of that bulk is going to need a spec 15:30:05 that shouldn't be seen as a barrier; I like using the spec template b/c it helps me prevent forgetting things 15:30:22 I'm trying to remember, and maybe this is where a spec would help, why not enable/drive the deployed OS to self-manage SED ? 15:30:23 but given it'll change deployment flows that'll help us understand exactly how 15:31:34 I think this could just be a specific deploy interface, tbh, but those sorts of questions need to be sorted through 15:31:55 the why honestly is really important 15:32:01 bceause if we know why we can help more with the how :D 15:32:04 For me it's a new driver, that is impacting deploy interface, reboot, etc 15:32:22 Why activating this feature ? 15:32:33 Also, a related question, this references MBR. How does UEFI work with these sort of systems/devices because it seems like the model is to unlock, trigger a revisit to the boot sequence 15:32:55 drannou: paint the vision for us, although I do seriously think a spec document is in your future :) 15:33:14 MBR is not mandaroy, I put it because it's the "normal way to go", but for Ironic I don't think it's a good idea 15:33:23 (we do require such when we start talking adding interfaces/drivers, fwiw) 15:33:37 Ahh, okay. 15:33:52 No problem to do it, just if you have examples or documentation on how to do it, that would help me a lot 15:34:13 tons, in the opendev.org/openstack/ironic-specs repo, there is also a template to start from 15:34:20 Oh, there is a spec template, and it is glorious. 15:34:40 I often pull it down and use it for a template for personal projects, too, just because it's a useful checklist for "have I thought of all this stuff" 15:34:41 Wonderfull, I will check that and try to do it tomorrow 15:35:08 thanks! 15:35:09 Do you need more context on why we need SED exactly ? 15:35:14 Yes, exactly 15:35:16 we want the use case 15:35:22 tell us the problem you have, how this solves it 15:35:27 why SED managed by the OS doesn't solve it 15:35:31 and the why which drives the pattern of offloading the host OS awareness of SED 15:36:26 honestly, doesn't even matter so much if we have the use case, think it's valuable, etc 15:36:28 Theme wise, I think we kind of get it, we even have a kexec patch somewhere in gerrit you can take/use, but the why is kind of important overall 15:36:28 I will make a short version here : in EU, and more over in France, there is a new security certitication for wloud providers that is call "SecNumCloud", one of the spec is that, as a cloud provider, you need to give to your customer a way to completely encrypt hard drive 15:36:46 oh 15:36:48 Ah, so one of the key requirements here is that the customer holds the key 15:36:53 such that the machine can't independently boot 15:36:55 ugh 15:37:02 exactly 15:37:05 drannou: please include links to the regulation 15:37:12 ok 15:37:15 I suspect we have some reading we'll need to do 15:37:39 this is something that would likely need like 15:37:43 console or something like that 15:37:45 dang 15:37:57 So saying that, you see that there is a tons of implication, one is that if the host is power down, for any reason if the disk "leave" the host, data should be encrypted 15:38:01 how do you do this without the cloud provider being able to intercept? 15:38:33 Lots, and lots of layers of trust to establish 15:38:35 even if you used console and put in key that way, you can proxy it 15:38:45 This is a good use case, valuable. 15:38:50 Also impossible-sounding. 15:38:56 I'm glad it's your use case and not mine drannou ;) 15:39:08 No You don't really need the "super root admin with all super Power" have no acces to the key, but that should be "control" 15:39:10 eh, nothing is impossible, just depends on the size of the lever 15:39:37 Aight, I think we have a decent idea 15:39:44 drannou: this all still has to be written down btw 15:39:54 going to move on to... 15:40:00 #topic Open Discussion 15:40:02 Anything else? 15:40:12 https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/898723 15:40:13 Yeah, spec document would be needed with context of the regulation driving the need, and then lets try and wrap our heads around the spec 15:40:48 I have this PR that is waiting for reviews, and may be even a global discussion for your question JayF 15:41:11 yeah I just refreshed my comment and -1 15:41:17 In other news, I have written the first recipe down into a gdoc. 15:41:24 (Question arround DHCP on IPA) 15:42:36 Thanks drannou; hopefully folks have a look. I suspect reviews will start back up this week as people recover from PTG. 15:42:56 Ok wonderfull thx 15:43:18 last call before I close the meeting? 15:43:37 JayF: just commented 15:44:03 #endmeeting