15:00:07 <JayF> #startmeeting ironic
15:00:07 <opendevmeet> 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 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:07 <opendevmeet> The meeting name has been set to 'ironic'
15:00:13 <JayF> Hey guess what; another meeting!
15:00:20 <JayF> #topic Announcements/Reminder
15:00:21 <TheJulia> o/
15:00:29 <JayF> 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 <iurygregory> o/
15:00:48 <JayF> #topic Review action items from previous meeting
15:01:04 <JayF> #info JayF to backport ngs_save fix for networking_generic_swtich, cut a bugfix-version (not branch) release of it
15:01:13 <JayF> going to be honest, don't remember if I did this, checking
15:01:13 <rpittau> o/
15:01:27 <iurygregory> you did
15:01:32 <JayF> did it land?
15:01:39 <iurygregory> just need to update based on the reivew
15:01:45 <rpittau> JayF: re ironic docs: I think I replied too, or maybe not :P
15:01:57 <JayF> rpittau: ack, will add you to the meeting, I thought I missed someone
15:02:15 <JayF> rpittau: my IRC "highlights channel" is unreadable after the last week, for some reason :D
15:02:23 <JayF> iurygregory: I'll follow up on it
15:02:29 <JayF> #topic Caracal release Schedule
15:02:33 <rpittau> :D
15:02:35 <JayF> #link https://releases.openstack.org/caracal/schedule.html
15:02:55 <JayF> 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 <JayF> I doubt there's action for us to take this week for release in October :D
15:03:14 <JayF> #topic PTG Review
15:03:24 <JayF> #link https://etherpad.opendev.org/p/ironic-ptg-october-2023
15:03:47 <JayF> 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 <JayF> I wanna track any "JFDI" level items here
15:04:41 <JayF> 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 <JayF> 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 <JayF> #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 <JayF> #undo
15:05:36 <opendevmeet> 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 <JayF> #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 <JayF> 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 <JayF> #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 <JayF> #action JayF [from PTG] Setup IPA-builder in launchpad
15:07:33 <TheJulia> ... do we have periodics?
15:07:43 <JayF> all stable jobs run in periodics aiui
15:08:01 <JayF> #action masghar [from PTG] provide feedback about specific gaps in documentation,  fix if small, provide feedback if more sizable
15:08:10 <TheJulia> .. That doesn't seem right, but it could still be done and not obvious with the config
15:08:27 <JayF> 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 <JayF> TheJulia: either way; I'll dig as part of doign it
15:09:18 <JayF> #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 <JayF> that's tuesday LOL
15:09:52 <JayF> #action JayF [from PTG] email list about IntelIPMIManagement driver usage
15:10:25 <JayF> I don't see explicit actions bolded out of OVN/Redfish, TheJulia were there any?
15:10:43 <JayF> looks like maybe just make 3 bugs are the only actions there?
15:10:55 <TheJulia> JayF: None from OVN, it was more information/context setting
15:10:59 <TheJulia> Redfish, Let me glance again
15:11:11 <JayF> I think that's all the "small" actions AFAICT
15:11:21 <JayF> everything else is large enough to need a bug or to be in a workstream
15:11:51 <JayF> 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 <TheJulia> 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 <JayF> Oh, there is one other action not to drop
15:12:55 <TheJulia> Also, RFE for boot status, but nothing major really
15:12:57 <TheJulia> small building blocks
15:13:11 <JayF> #action JayF Book a meeting with stakeholders; TheJulia JayF and johnthetubaguy minimum, on Nova driver bug fixing/hunting
15:13:42 <JayF> If anyone wants in on that, please ask; only reason we didn't PTG it was so we'd be fresher :)
15:14:29 <JayF> Alright, anything else as follow-up to PTG before we move on?
15:14:50 <JayF> #topic Review Ironic CI Status
15:15:08 <JayF> 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 <rpittau> haven't seen any p[articular recurring or worrying failure since a while
15:16:42 <JayF> #topic RFE Review
15:16:45 <JayF> there's one up for review
15:16:50 <JayF> #link https://bugs.launchpad.net/ironic/+bug/2040236
15:17:19 <JayF> Reading this RFE, I'm not sure I want to approve it as written.
15:17:50 <JayF> The bug itself implies that it might add the config and only implement it for iRMC
15:18:04 <JayF> if we add a config under `[conductor]` to set that path, it needs to be respected throughout
15:18:32 <JayF> 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 <JayF> Just seems like there's enough edges there that an RFE bug might not be sufficient.
15:18:44 <JayF> WDYT?
15:18:57 <TheJulia> so... I guess I'm conflicted
15:19:07 <TheJulia> because verify_ca is supposed to take a path out of the box
15:19:11 <JayF> If it was like, [irmc]irmc_default_verify_ca_path
15:19:54 <TheJulia> I guess I don't understand *why* from the lp bug
15:20:23 <JayF> I'll comment in there, saying we were unable to approve because the scope and the "why" is unclear
15:20:26 <TheJulia> Why do we need a second level default
15:20:46 <iurygregory> 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 <JayF> 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 <JayF> of course :)
15:20:57 <iurygregory> and take async
15:20:58 <TheJulia> looks like they also want to add it as a node field
15:21:04 <TheJulia> which is... semi-problematic
15:21:21 <JayF> Yeah, we can't have that as a per-node override.
15:21:21 <TheJulia> not insurmountable, but yeah, better understanding of need is needed
15:22:08 <TheJulia> 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 <TheJulia> but then that requires you know internal details like location of files on disk and set/get that via an API
15:22:31 <JayF> [agent]verify_ca exists
15:22:34 <JayF> so does [ilo]verify_ca
15:22:42 <JayF> but nothing condcuctor-wide
15:23:47 <TheJulia> yeah, this is driver level for speaking with the remote BMC
15:23:47 <JayF> OK; so I think we need to needs-spec this then, if it's node level
15:23:52 <JayF> because we need to be very explicit about how we RBAC a setting to change the verify_ca settings per node
15:24:14 <JayF> Do you think that's overkill?
15:24:27 <TheJulia> RBAC wies, it would just need to be adminy user
15:24:30 <TheJulia> wise
15:24:42 <TheJulia> From a what is in the field wise, it really can't be a file path
15:25:01 <TheJulia> which makes this further challenging
15:25:07 <JayF> Why not? You'd expect the deployment tooling to do key management.
15:25:27 <TheJulia> Think user not having filesystem access to the remote server where Ironic is running
15:25:35 <TheJulia> they don't *actually* know where the files are for that CA
15:25:38 <JayF> 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 <TheJulia> best they can supply, realistically, is a URL
15:25:54 <JayF> oh, CA is not a private key
15:25:57 <JayF> it's a public key
15:26:00 <TheJulia> correct
15:26:04 <TheJulia> but they want to provide paths
15:26:10 <JayF> 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 <JayF> this needs to be specced.
15:26:34 <TheJulia> JayF: yeah, basically it does need to be written up in a more verbose form
15:26:51 <TheJulia> I get their basic intention after skimming the openshift enhancement doc
15:27:16 <TheJulia> and after you looked at the config, we just need to find a sensible path forward
15:28:36 <JayF> commented, tagged needs-spec
15:28:40 <JayF> drannou: that was not on the agenda
15:28:45 <JayF> drannou: usually we prefer those be on the agenda first
15:28:56 <JayF> but I'm curious :)
15:29:03 <drannou> no problem, we can discuss about it when you want
15:29:42 <JayF> 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 <JayF> a feature of that bulk is going to need a spec
15:30:05 <JayF> 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 <TheJulia> 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 <JayF> but given it'll change deployment flows that'll help us understand exactly how
15:31:34 <TheJulia> I think this could just be a specific deploy interface, tbh, but those sorts of questions need to be sorted through
15:31:55 <JayF> the why honestly is really important
15:32:01 <JayF> bceause if we know why we can help more with the how :D
15:32:04 <drannou> For me it's a new driver, that is impacting deploy interface, reboot, etc
15:32:22 <drannou> Why activating this feature ?
15:32:33 <TheJulia> 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 <TheJulia> drannou: paint the vision for us, although I do seriously think a spec document is in  your future :)
15:33:14 <drannou> 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 <TheJulia> (we do require such when we start talking adding interfaces/drivers, fwiw)
15:33:37 <TheJulia> Ahh, okay.
15:33:52 <drannou> 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 <TheJulia> tons, in the opendev.org/openstack/ironic-specs repo, there is also a template to start from
15:34:20 <JayF> Oh, there is a spec template, and it is glorious.
15:34:40 <JayF> 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 <drannou> Wonderfull, I will check that and try to do it tomorrow
15:35:08 <JayF> thanks!
15:35:09 <drannou> Do you need more context on why we need SED exactly ?
15:35:14 <JayF> Yes, exactly
15:35:16 <JayF> we want the use case
15:35:22 <JayF> tell us the problem you have, how this solves it
15:35:27 <JayF> why SED managed by the OS doesn't solve it
15:35:31 <TheJulia> and the why which drives the pattern of offloading the host OS awareness of SED
15:36:26 <JayF> honestly, doesn't even matter so much if we have the use case, think it's valuable, etc
15:36:28 <TheJulia> 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 <drannou> 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 <TheJulia> oh
15:36:48 <JayF> Ah, so one of the key requirements here is that the customer holds the key
15:36:53 <TheJulia> such that the machine can't independently boot
15:36:55 <TheJulia> ugh
15:37:02 <drannou> exactly
15:37:05 <TheJulia> drannou: please include links to the regulation
15:37:12 <drannou> ok
15:37:15 <TheJulia> I suspect we have some reading we'll need to do
15:37:39 <JayF> this is something that would likely need like
15:37:43 <JayF> console or something like that
15:37:45 <JayF> dang
15:37:57 <drannou> 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 <JayF> how do you do this without the cloud provider being able to intercept?
15:38:33 <TheJulia> Lots, and lots of layers of trust to establish
15:38:35 <JayF> even if you used console and put in key that way, you can proxy it
15:38:45 <JayF> This is a good use case, valuable.
15:38:50 <JayF> Also impossible-sounding.
15:38:56 <JayF> I'm glad it's your use case and not mine drannou ;)
15:39:08 <drannou> 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 <TheJulia> eh, nothing is impossible, just depends on the size of the lever
15:39:37 <JayF> Aight, I think we have a decent idea
15:39:44 <JayF> drannou: this all still has to be written down btw
15:39:54 <JayF> going to move on to...
15:40:00 <JayF> #topic Open Discussion
15:40:02 <JayF> Anything else?
15:40:12 <drannou> https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/898723
15:40:13 <TheJulia> 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 <drannou> I have this PR that is waiting for reviews, and may be even a global discussion for your question JayF
15:41:11 <JayF> yeah I just refreshed my comment and -1
15:41:17 <TheJulia> In other news, I have written the first recipe down into a gdoc.
15:41:24 <drannou> (Question arround DHCP on IPA)
15:42:36 <JayF> Thanks drannou; hopefully folks have a look. I suspect reviews will start back up this week as people recover from PTG.
15:42:56 <drannou> Ok wonderfull thx
15:43:18 <JayF> last call before I close the meeting?
15:43:37 <TheJulia> JayF: just commented
15:44:03 <JayF> #endmeeting