| rpittau | good morning ironic! o/ | 07:57 |
|---|---|---|
| abongale[m] | Good Morning Ironic, I am curious about log file size. Is there any upper limit to how big a log size can be? | 10:19 |
| vsaienko | hello ironic community, do you know if serial console in horizon should work only for instances when admin explicitly enabled console on the node? and why we can't enable console for the node automatically when requesting console url? | 10:22 |
| iurygregory | good morning Ironic, I'm back o/ | 10:53 |
| masghar | Welcome back, Iury! | 11:05 |
| iurygregory | tks | 11:10 |
| vsaienko | ironic team please review https://review.opendev.org/c/openstack/nova/+/942575 and https://review.opendev.org/c/openstack/openstacksdk/+/942533 fixes broken serial console in horizon, its broken in Caracal as well (did not check earlier releases, so needs a backport) | 11:40 |
| dtantsur | +2 on SDK, cannot do much on Nova (but left a few nits) | 11:43 |
| cardoe | dtantsur: not sure if ya wanna look at https://review.opendev.org/c/openstack/ironic/+/942496 as well but that's what I need so that I can use the anaconda deploy interface with glance. | 14:04 |
| cardoe | It's been broken for a few releases. | 14:04 |
| TheJulia | good morning | 14:09 |
| TheJulia | vsaienko: serial console, not really. Shellinabox is a dead project. Most nova folks won't run the serial console proxy which afaik is the needful for the socat console. Truthfully, it also requires IPMI and that is just a not great idea in general. Enabling the console for all nodes also increases risk of conflicts and lockouts as well. Its just asking for problems. | 14:11 |
| vsaienko | TheJulia: thanks, but right now we do not have other alternative that socat, shellinabox is deprecated and going to be removed? do we have any other replacement? | 14:13 |
| TheJulia | vsaienko: serial console, no. We've learned serial consoles are actually really bad for modern kernel as well if there are high packet loads on the hosts | 14:14 |
| TheJulia | vsaienko: we've been working on graphical consoles which are less bad if you have the framebuffer turned on | 14:14 |
| vsaienko | what are currently available options for graphical console? | 14:15 |
| TheJulia | abongale[m]: The limit would really depend on how logging is being done. Most often log files are being handled by the process launcher, not ironic itself. | 14:16 |
| TheJulia | vsaienko: stevebaker[m] has patches in review how to start building the framework to do it, I think dell is his primary first target, then ilo, then supermicro. | 14:17 |
| TheJulia | vsaienko: but, the key to that is "in review" | 14:17 |
| TheJulia | https://review.opendev.org/q/topic:%22novnc_proxy%22 | 14:41 |
| cardoe | Trying to write a tempest change for my anaconda stuff... I notice that anaconda is marked as non-voting by you TheJulia. Any particular reason? | 14:41 |
| TheJulia | cardoe: the reason was largely failure rate related, I haven't re-evaluated it since then. So if it look solid, cool to change, but if it fails often/easily, then it needs more work/hardeing/luck | 14:42 |
| TheJulia | speaking of ci failures, looks like we're seeing a lot of cirros vms tartup and no ping or ssh :( | 14:43 |
| TheJulia | s/vms tartup/vm startup/ | 14:43 |
| opendevreview | Doug Goldstein proposed openstack/ironic master: deploy: allow anaconda to use the provisioning network https://review.opendev.org/c/openstack/ironic/+/942590 | 14:43 |
| cardoe | plus https://review.opendev.org/c/openstack/ironic/+/942496 lead to me almost being able to install ESXi | 14:44 |
| cardoe | I need to run some of the instance metadata into the kickstart file | 14:44 |
| cardoe | But if I don't say that it's a touchless install and manually answer the questions on the console then it works. | 14:45 |
| rpittau | #startmeeting ironic | 15:00 |
| opendevmeet | Meeting started Mon Feb 24 15:00:07 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 | #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_February_24.2C_2025 | 15:00 |
| iurygregory | o/ | 15:01 |
| masghar | o/ | 15:02 |
| rpittau | let's wait a couple of minutes for people to join :) | 15:02 |
| cardoe | o/ | 15:02 |
| dtantsur | o/ | 15:02 |
| TheJulia | o/ | 15:02 |
| cardoe | I forgot to add it to the agenda but can we discuss sushy release? | 15:02 |
| cid | o/ | 15:02 |
| rpittau | well I think we're good with quorum :) | 15:02 |
| rpittau | cardoe: it's there actually, I added it | 15:03 |
| rpittau | #topic Announcements/Reminders | 15:03 |
| rpittau | Standing reminder to review patches tagged ironic-week-prio and to hashtag any patches ready for review with ironic-week-prio: | 15:03 |
| rpittau | #link https://tinyurl.com/ironic-weekly-prio-dash | 15:03 |
| rpittau | some patches to review there, need to get them quick as the time is running out for the release | 15:04 |
| kubajj | o/ | 15:04 |
| rpittau | #info 2025.1 Epoxy Release Schedule | 15:04 |
| rpittau | #link https://releases.openstack.org/epoxy/schedule.html | 15:04 |
| iurygregory | I will prioritize review in sushy, I was on PTO | 15:04 |
| rpittau | we're at R-5 ! | 15:05 |
| rpittau | feature freeze is upon us | 15:05 |
| JayF | o/ | 15:05 |
| rpittau | so anything that we want to go in Epoxy needs to merge before EoW | 15:05 |
| rpittau | I will also start working on the cycle highlights that are due next week | 15:06 |
| rpittau | #info Flamingo PTG will take place place April 7-11, 2025! | 15:07 |
| rpittau | don't forget to register! | 15:07 |
| rpittau | the etherpad is ready here: | 15:07 |
| rpittau | #link https://etherpad.opendev.org/p/ironic-ptg-april-2025 | 15:07 |
| cardoe | grrr there was something I was suppose to add there. | 15:07 |
| rpittau | anything else to announce/remind ? | 15:08 |
| JayF | Ironic is DPL; or will be at the flip of the cycle. | 15:08 |
| JayF | I will work with TC to ensure that change merges | 15:08 |
| iurygregory | tks JayF | 15:08 |
| rpittau | yep, when Epoxy is released ironic will switch to DPL | 15:08 |
| * JayF hands rpittau his "Last PTL of Ironic Ever (maybe)" sash | 15:09 | |
| rpittau | :D | 15:09 |
| rpittau | thanks! | 15:09 |
| rpittau | anything else or we can move to the discussion topics? | 15:10 |
| rpittau | ok moving on | 15:11 |
| rpittau | #topic Discussion Topics | 15:11 |
| rpittau | #info migrate sushy-oem-idrac to sushy | 15:11 |
| rpittau | #link https://review.opendev.org/c/openstack/sushy/+/940557 | 15:11 |
| rpittau | I guess we need to move this to the next cycle | 15:11 |
| rpittau | sushy release is already late | 15:12 |
| TheJulia | Well, we can do it, it just won't make this cycle | 15:12 |
| rpittau | yeah | 15:12 |
| rpittau | that's what I meant :) | 15:12 |
| iurygregory | omg +6550 | 15:12 |
| cardoe | I just don't know what we need to do. | 15:12 |
| TheJulia | and by do it, I mean approve the patches right now | 15:12 |
| cardoe | Cause it works. | 15:12 |
| cardoe | It even installs along side together just fine | 15:12 |
| cardoe | It's just "wrong" to install both" | 15:12 |
| rpittau | it's a last minute huge change | 15:13 |
| JayF | yeah; it seems like the ideal thing to have at the top of the cycle | 15:13 |
| rpittau | and IMHO we probably need to deprecate sushy-oem-idrac first | 15:13 |
| JayF | I know it's painful to wait but it's extremely good it's lined up | 15:13 |
| cardoe | https://review.opendev.org/c/openstack/ironic/+/942520 is all that ironic needed. | 15:13 |
| rpittau | cardoe: you did a great job, thanks a lot for that :) | 15:13 |
| cardoe | I'm good with pushing to the next cycle and deprecating sushy-oem-idrac first. | 15:14 |
| rpittau | that's another last minute change, FF is this week | 15:14 |
| rpittau | cardoe: perfect | 15:14 |
| rpittau | thanks | 15:14 |
| JayF | Traditionally Ironic hasn't complied with overall OpenStack FF | 15:14 |
| JayF | those are usually for cycle-with-rc, not cycle-with-intermediary | 15:14 |
| iurygregory | ++ | 15:14 |
| cardoe | I just want to know WHAT we want to do to formally merge it all. | 15:14 |
| dtantsur | If it's co-installable, we might JFDI right after branching ironic | 15:15 |
| rpittau | yep | 15:15 |
| JayF | ++ | 15:15 |
| rpittau | I'd say we can merge the sushy change whenever, but wait for the ironic one | 15:15 |
| dtantsur | This may cause troubles for people consuming master | 15:16 |
| dtantsur | but probably not critical troubles | 15:16 |
| cardoe | I dunno what trouble it will cause for packagers. Cause they do install the same file (for the entry point). And while pip doesn't care. An RPM built up from a Python package might care if they both install the same file? | 15:17 |
| rpittau | mmmm well it won't be released, so if we see issues we're more relaxed in fixing them | 15:17 |
| cardoe | So I'd rather hold off and understand WHAT I need to do to communicate the change the best way. | 15:17 |
| cardoe | But that's what I'm saying.. I dunno how to best communicate that. | 15:17 |
| rpittau | production RPMs usually are built from releases, not from master | 15:18 |
| dtantsur | yeah, I'm just being overly cautious | 15:18 |
| rpittau | :) | 15:18 |
| dtantsur | but *at latest* when Ironic is branches we should just merge everything | 15:18 |
| dtantsur | * is branched | 15:18 |
| rpittau | yep | 15:18 |
| rpittau | I'll release the krak... the sushy release then | 15:19 |
| dtantsur | pull the lever! | 15:20 |
| rpittau | done! :D | 15:20 |
| iurygregory | ship it! | 15:20 |
| rpittau | cardoe: I just udpated the ironic change so it's clear what we need to do | 15:20 |
| rpittau | the sushy change can go in at will | 15:21 |
| rpittau | are we good to move on? | 15:21 |
| rpittau | ok! | 15:23 |
| rpittau | #info ironic-lib deprecation | 15:23 |
| rpittau | #link https://review.opendev.org/q/topic:%22ironic-lib-deprecation%22 | 15:23 |
| rpittau | I think we're waiting for https://review.opendev.org/c/openstack/governance/+/939278 ? | 15:23 |
| JayF | yes, I'll nudge TC about that, too | 15:23 |
| rpittau | thanks JayF :) | 15:23 |
| rpittau | any other discussion topics for today? | 15:24 |
| cid | RFEs | 15:25 |
| rpittau | cid: yes! | 15:25 |
| rpittau | which one(s) ? | 15:25 |
| cid | This, https://bugs.launchpad.net/ironic/+bug/2098884 | 15:26 |
| cid | I have updated the agenda with the links to the rest. | 15:26 |
| JayF | I assume (cc: TheJulia) that the redfish serial interface is shaped similarly to the ipmi stuff? | 15:27 |
| JayF | If so, seems like an obvious JFDI | 15:27 |
| TheJulia | JayF: It really doesn't exist afaik | 15:27 |
| dtantsur | Well, it can be over IPMI or SSH | 15:27 |
| JayF | then what is the RFE wanting us to do? | 15:27 |
| dtantsur | (or OEM, yay) | 15:27 |
| JayF | wait, what | 15:27 |
| TheJulia | well, true, it can be | 15:27 |
| JayF | redfish bmcs expose serial consoles over ipmi, is that what you just said? | 15:27 |
| dtantsur | JayF: Redfish specifies IPMI or SSH as possible protocols for serial console :) | 15:27 |
| TheJulia | I've *yet* to see a bmc that offers that though | 15:27 |
| dtantsur | \o/ | 15:28 |
| TheJulia | possible being the magical aspect :) | 15:28 |
| JayF | oroborous is gonna sue hardware companies for gimmick infringement lol | 15:28 |
| dtantsur | If we did not have a VPN outage, I would check our internal Redfish dumps | 15:28 |
| TheJulia | wheeeeeeee | 15:28 |
| TheJulia | Anyway, yeah, given its a possible option, jfdi just seems to make sense to me | 15:28 |
| dtantsur | TheJulia: is what you offer basically just adding ipmitool-socat to the list of supported interfaces? | 15:29 |
| dtantsur | I.e. without actually checking the Redfish data? | 15:29 |
| JayF | I assume we'd actually need some glue code, the RFE implies we'd have to do some credential and metadata passing | 15:29 |
| TheJulia | dtantsur: Thinking so *and* likely allowing the ipmitool exec code to understand it can grab username/password/host address from the redfish fields | 15:30 |
| cardoe | TheJulia: does that just work? | 15:30 |
| TheJulia | I've not looked closely at it, so my brain is running form memory, but it should just work if the values are already populated for ipmi | 15:30 |
| TheJulia | and the interface is available/loaded | 15:31 |
| dtantsur | Hmm. I don't object to it, but let's make sure (naming etc) that we can introduce a more proper Redfish interface later (even if it looks unlikely right now) | 15:31 |
| cardoe | https://www.dmtf.org/sites/default/files/Redfish_Serial_Console_Enhancements_05-2020_WIP.pdf afaik is what I had bookmarked for changes | 15:31 |
| JayF | IPMISoCatConsoleViaRedfish console class coming up? :D | 15:31 |
| TheJulia | I suspect our introduced interfaces will be more-so graphical :) | 15:31 |
| TheJulia | but yeah | 15:31 |
| TheJulia | Eh, I suspect some folks would prefer ssh if we have a known working example | 15:32 |
| TheJulia | but I'm just trying to do the needful, not boil an ocean | 15:32 |
| * TheJulia is working on ocean boiling network switching at the moment | 15:32 | |
| TheJulia | (well, testing) | 15:32 |
| vsaienko | ironic team, can somebody please point me to the code where connectivity between multinode devstack builds is configured on CI? I'm looking similar place https://review.opendev.org/c/openstack/devstack-gate/+/335981/7/devstack-vm-gate.sh in zuul ansible roles | 15:34 |
| rpittau | vsaienko: let's wait for after the meeting for that, thanks :) | 15:35 |
| cardoe | There's a few more RFEs. Let's go through them. | 15:35 |
| cardoe | cid said 4 but I see 5. :shifty: | 15:36 |
| cardoe | https://bugs.launchpad.net/ironic/+bug/2098886 | 15:36 |
| TheJulia | folk scan blame me for some of these, I was quickly filing bugs from discussions | 15:36 |
| cid | :) | 15:36 |
| cardoe | #link https://bugs.launchpad.net/ironic/+bug/2098886 | 15:36 |
| cardoe | To steal rpittau's thunder a little. | 15:36 |
| TheJulia | This one comes from a disucssion where someone conveyed they really neede to deploy a whole bunch of identical machines, and didn't care about fine details | 15:37 |
| TheJulia | and didn't also care about much of the openstacky primitives | 15:37 |
| dtantsur | Oh. TheJulia is going to hate me, but this should be reworked in terms of allocations and ideally the deployment API | 15:37 |
| TheJulia | they just wanted it to be single-action oriented | 15:37 |
| dtantsur | maybe not allocations, maybe only the deployment API.. | 15:37 |
| TheJulia | The key aspet is they are just a tenant with restricted views and basically wanted bulk deployments | 15:37 |
| TheJulia | dtantsur: actually, I was kind of thinking something along the basic idea but sans allocations since that is something else they need to interact with | 15:38 |
| TheJulia | basically, they just want a bulk interactions interface | 15:38 |
| TheJulia | where the conductor can solve the details | 15:38 |
| dtantsur | But in all honesty.. it's a simple loop in Python, no? | 15:38 |
| TheJulia | I realize, the idea needs a lot of work, so its fine if people want to put notes in and we can move on | 15:38 |
| TheJulia | they don't want to have to think/manage at that level | 15:38 |
| dtantsur | I think a much bigger usability issue is the lack of a deployment API, which caused metalsmith | 15:39 |
| JayF | I don't really like the idea of that at all tbh | 15:39 |
| JayF | == dtantsur | 15:39 |
| dtantsur | if we have deployment API, what you need would be 4 lines of Python probably | 15:39 |
| TheJulia | They don't want that, they want a single rest call. | 15:39 |
| cardoe | So honestly I think this puts complexity into Ironic that should really be done by the caller of the API. | 15:39 |
| TheJulia | fair enough | 15:39 |
| cardoe | Cause what should be the result if 1 fails and 3 succeed cause of locking? | 15:40 |
| JayF | I mean, I'd rather them have a short script or client hack than have ironic do a bad job of batching | 15:40 |
| TheJulia | I'm just the proxy, I'm not going to advocate endlessly for this | 15:40 |
| JayF | because it's not... ^^^ yes exactly cardoe is going down my path | 15:40 |
| dtantsur | My comment is not a hard no, but I pretty firmly believe we need to solve the general deployment UX first | 15:40 |
| JayF | yeah; have a "deploy one in one rest API call" | 15:40 |
| JayF | before "deploy many in one rest API call" | 15:40 |
| TheJulia | I sort of think one of the next ones actually approaches that, so I think we can carry on to the next rfe? | 15:41 |
| cardoe | #link https://bugs.launchpad.net/ironic/+bug/2098888 | 15:42 |
| cardoe | Feels like a better replacement for shellinabox? | 15:42 |
| JayF | I'm assuming the mechanism for this would be a sidecar container, like for redfish gfx console? | 15:43 |
| JayF | I'd prefer something like this not end up with ssh connections routed through/proxied by a conductor | 15:43 |
| dtantsur | Yeah, I'm also curious about technical details, but the idea sounds good | 15:43 |
| TheJulia | Socat console would get you a graphical console | 15:44 |
| TheJulia | this is just... ssh wrapping the connection | 15:44 |
| TheJulia | JayF: to be determined, but if we follow the existing model of console interfaces each responsible conductor would manage the "sshds" | 15:45 |
| JayF | I have a lot of security nervousness if those sshds are colocated with the conductor, but that's implementation detail territory | 15:45 |
| TheJulia | indeed | 15:45 |
| dtantsur | I potential issue may be the requirements on root access | 15:45 |
| dtantsur | We've just got rid of oslo.rootwrap | 15:45 |
| dtantsur | Could be a case for a small companion service | 15:46 |
| TheJulia | at least a long time ago, you could invoke sshd without root if you were doing a highly sepcific configuraiton | 15:46 |
| dtantsur | hmmm | 15:46 |
| dtantsur | I'd read a more detailed proposal, be it in a spec or simply on LP | 15:46 |
| TheJulia | specific configurations would be be the soup of the day for something like this | 15:46 |
| dtantsur | but I'm not against the idea | 15:46 |
| TheJulia | ack | 15:46 |
| rpittau | TheJulia: yeah you can do that with a user config | 15:46 |
| TheJulia | rpittau: yup | 15:47 |
| JayF | Yeah the idea seems good here but likely valuable to write more details (if it were me I'd do a spec) | 15:47 |
| dtantsur | We really need some form between an RFE and a spec | 15:47 |
| TheJulia | Okay, onward! | 15:47 |
| rpittau | or just add more details to the RFE ? | 15:47 |
| JayF | eh; I think it's mainly "don't be a stick in the mud when reviewing specs for minor things" :D | 15:47 |
| dtantsur | true :D | 15:47 |
| JayF | I appreciate the structure, but maybe that's just me | 15:48 |
| TheJulia | onward? | 15:48 |
| JayF | onward! | 15:49 |
| rpittau | #link https://bugs.launchpad.net/ironic/+bug/2098694 | 15:50 |
| TheJulia | Just an idea placeholder for the aformentioned serial console topic | 15:51 |
| dtantsur | I guess the blocking concern is lack of hardware? | 15:51 |
| JayF | is that a differently worded version of the other two RFEs we've looked at around ssh->socat and ipmi-over-redfish consoles? | 15:51 |
| rpittau | I was wondering the same | 15:52 |
| TheJulia | I added this one as "we should look into this in general, not specifically" | 15:52 |
| TheJulia | so there is no ipmi-over-redfish console and this is entirely unrelated to ssh->socat->ipmitool sol | 15:52 |
| JayF | I'm happy for the feature to exist; but I would not have a use case or consume it :) | 15:53 |
| TheJulia | This might be a source of redfish-ssh console or soemthing like that | 15:53 |
| dtantsur | This is probably ENEEDSPEC | 15:53 |
| dtantsur | Generally valid idea but we don't have enough information to approve it | 15:53 |
| JayF | seems like this is less an RFE at this point and more a place to put research until we see what the feature owuld loook like | 15:53 |
| dtantsur | ++ | 15:53 |
| rpittau | +1 | 15:54 |
| JayF | RFE: research for enhancement lol | 15:54 |
| dtantsur | :D | 15:55 |
| rpittau | :) | 15:55 |
| rpittau | next (and last) one ? | 15:55 |
| rpittau | #link https://bugs.launchpad.net/ironic/+bug/2099906 | 15:55 |
| JayF | wait, really? | 15:56 |
| JayF | +2 JFDI | 15:56 |
| rpittau | yep not a lot to discuss there | 15:56 |
| cardoe | What do ya want the field called? | 15:56 |
| dtantsur | Is it similar to node.description? | 15:56 |
| dtantsur | because it sounds like node.description | 15:56 |
| TheJulia | a port.description filed? | 15:57 |
| TheJulia | field | 15:57 |
| * TheJulia cannot type today | 15:57 | |
| cardoe | port.description works for me. | 15:57 |
| rpittau | sounds good | 15:57 |
| TheJulia | so one last item I wanted to bring up | 15:57 |
| TheJulia | if we've got time | 15:57 |
| rpittau | we have 2:25 minutes :) | 15:57 |
| TheJulia | #link https://bugs.launchpad.net/ironic/+bug/2098697 | 15:57 |
| dtantsur | A solid idea, definitely needs a spec in my book | 15:58 |
| TheJulia | The idea is "it would be really nice if we didn't have to think in neutron primitives and have a vif" so to enable a model where ironic can fill the gap to it's neutron preferred data model, or even non-neutron usage models with some automatic logic | 15:58 |
| JayF | Well, I wonder if at the PTG | 15:58 |
| JayF | we should try to have a chat with neutron/nova/ironic devs and see if there's a better path forward including ideas like this | 15:58 |
| TheJulia | This is semi-disjointed, because a nova user will always send us a vif | 15:59 |
| JayF | (that's not an instead; that's an in-addition-to / as a part of) | 15:59 |
| TheJulia | well, nova will do it | 15:59 |
| JayF | TheJulia: well, I'm asking, is there a world where there'd be value in Nova not doing it, and Ironic doing it | 15:59 |
| TheJulia | nova (last time I looked) had paths to magically get you a vif | 15:59 |
| JayF | It seems like pushing some of the network config to Ironic/neutron without nova involved could lead to more flexibility, especially for cases where you are owner/lessee and have some control over the node | 16:00 |
| TheJulia | I would avoid nova like the plauge since nova has all of the logic "if we get handed a network, we need to do x, if we get handed a this other value we need to do y logic" | 16:00 |
| JayF | ack | 16:00 |
| cardoe | Gonna have to chat with the nova folks about that change. | 16:00 |
| cardoe | I know they've been breaking out the vif bits into a separate os-vif library. | 16:01 |
| TheJulia | I'm just thinking, is there a path to make the non-nova user life easier | 16:01 |
| dtantsur | non-nova but with neutron? | 16:01 |
| TheJulia | yup | 16:01 |
| dtantsur | metalsmith-style | 16:01 |
| dtantsur | okay, yeah | 16:01 |
| TheJulia | or, potentially without | 16:01 |
| TheJulia | sort of depends on where the matrix needs to end up overall, but not trying to join other stuff together in a grand vision at the moment | 16:02 |
| TheJulia | hopefully, that makes sense | 16:02 |
| JayF | I understand, I do worry sometimes that we haven't taken a high level view of the integrated process in a while, and often assume that the status quo is unchangable | 16:03 |
| rpittau | we can bring up the topic next time for a deeper discussion if needed, or even add something to the PTG etherpad | 16:03 |
| JayF | I wanted to imagine for a second that we could change the status quo :) | 16:03 |
| rpittau | alright thanks everyone, going to close the meeting now :) | 16:04 |
| rpittau | #endmeeting | 16:04 |
| opendevmeet | Meeting ended Mon Feb 24 16:04:30 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:04 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2025/ironic.2025-02-24-15.00.html | 16:04 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2025/ironic.2025-02-24-15.00.txt | 16:04 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2025/ironic.2025-02-24-15.00.log.html | 16:04 |
| dtantsur | Unfortunately, did not have time during the meeting, but | 16:04 |
| dtantsur | we have discussed a few small(ish) RFEs, and some of you may have more in their heads | 16:04 |
| dtantsur | we're currently looking for a project for Outreachy | 16:05 |
| dtantsur | so if you have something that is rather on the small side and self-contained, let me know | 16:05 |
| dtantsur | (if you want to (co-)mentor, also let me know) | 16:05 |
| TheJulia | ++ | 16:06 |
| dtantsur | "Let's implement this Redfish feature" can be a good one, especially if it can be tested on sushy-tools | 16:06 |
| opendevreview | Takashi Kajinami proposed openstack/python-ironicclient master: Drop remaining use of iteritems https://review.opendev.org/c/openstack/python-ironicclient/+/942613 | 16:07 |
| JayF | I wonder if cardoe has something ingestible for OEM support stuff, like integrating ilo .... but that's as far from "Testable in sushy-tools" as possible | 16:08 |
| TheJulia | JayF: fwiw, personally, I'm trying to avoid scope creeping efforts to preserve my sanity and capacity | 16:08 |
| JayF | cid: ^ you might be a good person to think about what'd be good for an outreachy project | 16:08 |
| TheJulia | dtantsur: it would be super neat if with redfish we could somehow cleanly account for how much power a baremetal node used during it's deployed lifetime.... | 16:08 |
| cardoe | Yeah I was thinking about that too JayF | 16:08 |
| TheJulia | #crazy_idea | 16:08 |
| JayF | TheJulia: I understand that; sadly for me I am having to go the other direction more these days and try to get things working smoother together | 16:08 |
| masghar | TheJulia: Is that possible with redfish? | 16:09 |
| TheJulia | JayF: fair enough | 16:09 |
| TheJulia | masghar: why yes! Checkout the power supplies structural data in the standard | 16:09 |
| TheJulia | There *is* a counter in the standard | 16:09 |
| TheJulia | in kWh | 16:10 |
| dtantsur | Yep. The only problem is that we cannot ask the intern to write a spec. So we need to come up with a complete design *before* | 16:10 |
| TheJulia | dtantsur: exactly | 16:10 |
| TheJulia | I was musing, this might be something useful for node history | 16:10 |
| TheJulia | record it as an informational value | 16:10 |
| dtantsur | Me, I was thinking about configuring TLS certificates for virtual media | 16:10 |
| dtantsur | (and turning their validation on and off) | 16:10 |
| JayF | dtantsur: I'm giving satoshi most of the parts for a container hardware manager implementation and letting him do the spec-level research. It does depend on how well levelled the candidate is | 16:10 |
| TheJulia | if someone really needs it, they could grab it easily | 16:10 |
| dtantsur | JayF: we don't expect a very high level, and we have a hard timebox of 3 months | 16:11 |
| JayF | faif enough | 16:12 |
| cardoe | speaking of nova integration.. https://review.opendev.org/c/openstack/nova/+/942019 could take a nod from an ironic person | 16:16 |
| cardoe | and https://review.opendev.org/c/openstack/ironic/+/942496 I wanted to propose a follow on for master... that's a backport-able change. | 16:16 |
| cardoe | But rather than making our own dictionary... can we not just pass around the SDK Image object and use type annotations in our code for that? | 16:17 |
| cardoe | That would involve changing the tests | 16:17 |
| JayF | cardoe: tl;dr: -1, release note needed | 16:17 |
| cardoe | For which one? | 16:18 |
| JayF | oh, the first one | 16:18 |
| JayF | 942019 | 16:18 |
| dtantsur | access denied! | 16:18 |
| cardoe | should I open a nova bug too? | 16:18 |
| JayF | cardoe: you should do whatever nova requires for that to be backported | 16:18 |
| JayF | cardoe: IDK what that is off the dome | 16:18 |
| * dtantsur assumed JayF had a hardware token fire in IRC :D | 16:18 | |
| JayF | dtantsur: sdflkghsdfdsagdksjhkasgjld=== | 16:19 |
| * dtantsur is scared | 16:19 | |
| * TheJulia blinks | 16:21 | |
| TheJulia | JayF: you forgot to add "Bearer" to the front of that ;) | 16:22 |
| JayF | Bearer Metal kjshdgslkjdfgsdklasd=== | 16:23 |
| dtantsur | "Bearer Metal" could be the foundation for new stickers | 16:26 |
| * JayF finds an AI to ask "a bear playing the drums with a red fish" /s | 16:29 | |
| TheJulia | oh... my | 16:45 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: hooking in an external network simulator https://review.opendev.org/c/openstack/ironic/+/942298 | 16:47 |
| rpittau | good night! o/ | 17:06 |
| masghar | o\ | 17:07 |
| * frickler wonders how Bear Metal would sound, something between Heavy and Death with a touch of Melodic? ;) | 17:22 | |
| opendevreview | Adam McArthur proposed openstack/ironic-tempest-plugin master: Testing bad microversions on v1/conductors https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/942632 | 17:48 |
| opendevreview | Julia Kreger proposed openstack/ironic master: CI: Extend default timeouts slightly https://review.opendev.org/c/openstack/ironic/+/942633 | 17:50 |
| opendevreview | Adam McArthur proposed openstack/ironic-tempest-plugin master: Testing bad microversions on v1/XXX https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/942634 | 17:52 |
| opendevreview | Adam McArthur proposed openstack/ironic-tempest-plugin master: Testing bad microversions on v1/conductors https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/942632 | 17:53 |
| opendevreview | Adam McArthur proposed openstack/ironic-tempest-plugin master: Testing bad microversions on v1/runbooks https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/942634 | 17:53 |
| opendevreview | Adam McArthur proposed openstack/ironic-tempest-plugin master: Testing bad microversions on v1/portgroups and v1/node/{node_id}/portgroup https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/942636 | 17:59 |
| cardoe | When the IPA downloads the configdrive, is that a privileged operation? e.g. do I need a token? will the agent token work? | 18:01 |
| JayF | I know it's not /always/ privledged because we have swift-temp-urls modes for those (or at least, onmetal had it hacked in lol) | 18:02 |
| cardoe | So just looking at how the anaconda deploy interface makes the data available. And essentially it's all a special case. | 18:04 |
| cardoe | It creates a kickstart snippet of %post sections per file which have a bash variable with the contents of each file base64'd and the filename. It then writes that file out to the path un-base64'ing it. | 18:04 |
| cardoe | Just thinking how I can make this more generic. | 18:07 |
| * cid JayF: Re: <^ you might be a good person to think about what'd be good for an outreachy project>. That does sound like something within my purview. I will BRB with any that I think might be suitable. | 18:08 | |
| JayF | yeah, just keep it in mind and reach out to Dmitry if you find something :) | 18:08 |
| cid | Okay sure. In terms of scope, just Ironic or adjacent projects inclusive? | 18:10 |
| JayF | ironic projects and surrounding stuff | 18:12 |
| JayF | he specifically said something self-contained in redfish+sushy land might be preferable | 18:13 |
| cid | Dmitry: if you had a moment, about inspection rules. Should I get rid of Plugin Data action classes (based on your last review) | 18:13 |
| cid | Or the actions are meant to alter a copy of the plugin data object but no retuns... so I just remove the return statements. | 18:15 |
| JayF | cardoe: this is completely spitballing, and I'm making up this data structure, but ... {"deploy_files": ["some_esx_bs.lolvmware", "some_rs_bs.local"], "deploy_template_files": [ "kickstart_but_esx.template" ] } with some kinda documented "if it's a template, we will find and replace these magic variables with these magic strings | 18:16 |
| JayF | cardoe: if you want it to be custom, give the user the customization skills | 18:16 |
| JayF | cardoe: custom-installer interface here we come? | 18:16 |
| dtantsur | cid: please use the nick, my IRC client does not highlight on "Dmitry" (maybe it should?) :) | 18:19 |
| dtantsur | cid: re modifying plugin_data: I was under impression that we're passing a mutable object around | 18:20 |
| dtantsur | so any edits to it inside plugins or rules will immediately be visible to any subsequent operations | 18:20 |
| dtantsur | cid: re outreachy: we participate as part of the OpenStack community, so it has to be something inside OpenStack | 18:22 |
| cid | dtantsur, ++. I could quickly check again on devstack, but the last time I tested, unless I returned a copy, updates do not reflect to the output from `openstack baremetal node inventory save node-0 | python -m json.tool | less -S` | 18:22 |
| dtantsur | so metal3 would be a stretch (although improving the metal3 CI job on ironic potentially not) | 18:22 |
| cardoe | JayF: unfortunately that's using the direct deploy and the fact that there's an image I can write. But I cannot write an image. | 18:23 |
| cid | Might I be looking at the wrong place? | 18:23 |
| dtantsur | cid: yeah, let's double-check it. you're not calling copy() explicitly, are you? | 18:23 |
| JayF | cardoe: that's custom-agent; I'm suggesting a completely new thing | 18:23 |
| dtantsur | also custom-agent does not expect an image | 18:23 |
| dtantsur | it does expect IPA though | 18:24 |
| cid | dtantsur, re: explicit call: Erm, nop. So I will double-check ! | 18:26 |
| opendevreview | Verification of a change to openstack/ironic-python-agent master failed: Lockout agent command results if a token is received https://review.opendev.org/c/openstack/ironic-python-agent/+/942010 | 18:26 |
| dtantsur | cid: I have a headache now, remind me tomorrow (ideally a few hours earlier), I'll take another look at the patch | 18:27 |
| cid | Sure thing. I should have updated the patch by then. Here's the right place to look: https://review.opendev.org/c/openstack/ironic/+/942112 | 18:28 |
| dtantsur | cid: maybe a result of some sanitizing? | 18:28 |
| cid | dtantsur. I really don't know. I was thinking if it's possible the plugin data have never being written to memory at the point of an action call. | 18:30 |
| cid | I will just have to check once more to be sure. | 18:31 |
| dtantsur | it's just a Python dict | 18:31 |
| dtantsur | unless we accidentally copy it, it should be shared between all hooks and rules | 18:31 |
| cid | Right! | 18:31 |
| dtantsur | Remind me if I forget to take another look tomorrow | 18:37 |
| dtantsur | Tried now, but cannot think clearly | 18:38 |
| dtantsur | See you folks | 18:38 |
| cid | You can count on that :D o/ | 18:40 |
| opendevreview | Satoshi Shirosaka proposed openstack/ironic master: Add extra log to is_image_available https://review.opendev.org/c/openstack/ironic/+/942641 | 18:59 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: hooking in an external network simulator https://review.opendev.org/c/openstack/ironic/+/942298 | 19:04 |
| opendevreview | Merged openstack/ironic master: Add ironic-novncproxy service https://review.opendev.org/c/openstack/ironic/+/939191 | 19:06 |
| opendevreview | Jay Faulkner proposed openstack/ironic-lib master: Deprecate ironic-lib master branch https://review.opendev.org/c/openstack/ironic-lib/+/939277 | 19:18 |
| JayF | ^ is teed up for merge now, V+1 with noop jobs | 19:20 |
| JayF | I'll self-merge if it's not landed in a while, just would rather avoid if other folks are around | 19:20 |
| opendevreview | Merged openstack/ironic-lib master: Deprecate ironic-lib master branch https://review.opendev.org/c/openstack/ironic-lib/+/939277 | 19:22 |
| JayF | RIP https://opendev.org/openstack/ironic-lib 2015-2025 | 19:25 |
| JayF | only remaining changes needed have been cleaned up and must be approved by others | 19:25 |
| opendevreview | Satoshi Shirosaka proposed openstack/ironic-python-agent master: WIP Add ContainerHardwareManager https://review.opendev.org/c/openstack/ironic-python-agent/+/941714 | 19:50 |
| TheJulia | cardoe: one quick test on your properties fix. Just to make sure we don't end up in the same conundrum | 19:57 |
| satoshi | I'm trying to use the container for the cleaning process via Podman. It successfully downloads the image from the local registry but it has an issue running it because I cannot see the output. | 19:58 |
| satoshi | Do you have any idea about this? | 19:58 |
| satoshi | This is the change I have. https://review.opendev.org/c/openstack/ironic-python-agent/+/941714 | 19:58 |
| JayF | Can you pastebin the output that you got form the agent machine? the full boot | 19:58 |
| satoshi | Does the paste bin has the length limit? I canno paste it fully | 20:17 |
| JayF | Try just hitting the upload button in irc cloud and telling it post text snippet | 20:24 |
| JayF | I think the limit for that is something like 100K | 20:24 |
| JayF | If it's still too big, just pair it down to the parts that come from after the IPA starts | 20:25 |
| satoshi | https://www.irccloud.com/pastebin/AeWNGhat/ | 20:31 |
| satoshi | https://www.irccloud.com/pastebin/fYo7ttaF/ | 20:33 |
| satoshi | https://www.irccloud.com/pastebin/jzmQ6FeX/ | 20:33 |
| satoshi | https://www.irccloud.com/pastebin/E531hdaK/ | 20:33 |
| satoshi | https://www.irccloud.com/pastebin/pYLWgGUe/ | 20:33 |
| cardoe | TheJulia: so like I was saying in the meeting. I wanna refactor the code we've got to just use the SDK Image object and use some type annotations around that if that's okay. But that'd be a bigger non-backport-able change. | 20:39 |
| TheJulia | speaking of meetings, I'm in a meeting right now :( | 20:40 |
| JayF | satoshi: https://review.opendev.org/c/openstack/ironic-python-agent/+/941714/6#message-562fd498ba6dba41664d1c27ac22c4ad39fdb3ca I think your root cause is around logging not working, not around the container not working | 20:40 |
| cardoe | one head scratcher with this anaconda deploy... it's tossing a file in the conductor called "disk" and it's a gzipped ELF.. no idea what it is. | 20:53 |
| JayF | are you sure that's what it is? and not just file doing a bad job id'ing it? | 20:54 |
| cardoe | I've ungzipped it and it's coming up as a 386 ELF. | 20:54 |
| cardoe | So maybe | 20:55 |
| JayF | https://opendev.org/openstack/oslo.utils/src/branch/master/oslo_utils/imageutils/cli.py#L31 | 20:55 |
| JayF | run that on it | 20:55 |
| JayF | in verbose | 20:55 |
| JayF | see if it finds an image | 20:55 |
| cardoe | okay. I'm basically trying to figure out how to get the configdrive over to my ESXi installer. | 20:56 |
| cardoe | I see the kickstart stuff templates it out in its only syntax. | 20:56 |
| cardoe | That's why I was asking how the agent got the config drive. | 20:56 |
| JayF | posted to standby.prepare_image | 20:58 |
| JayF | it seems | 20:58 |
| JayF | ...as either a gzip+base64 blob | 20:58 |
| JayF | or as a URL | 20:58 |
| JayF | per the pydoc on that method | 20:58 |
| cardoe | 'agent_status': 'start', 'agent_status_message': 'Deployment starting. Running pre-installation scripts.', | 21:00 |
| cardoe | Such excite. Many wow. | 21:00 |
| opendevreview | Adam McArthur proposed openstack/ironic-tempest-plugin master: Testing bad microversions on v1/conductors https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/942632 | 21:20 |
| opendevreview | Adam McArthur proposed openstack/ironic-tempest-plugin master: Testing bad microversions on v1/portgroups and v1/node/{node_id}/portgroup https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/942636 | 21:25 |
| opendevreview | Satoshi Shirosaka proposed openstack/ironic-python-agent master: WIP Add ContainerHardwareManager https://review.opendev.org/c/openstack/ironic-python-agent/+/941714 | 21:30 |
| opendevreview | Adam McArthur proposed openstack/ironic-tempest-plugin master: Testing bad microversions on v1/runbooks https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/942634 | 21:32 |
| satoshi | jay: Updated the code as advised. Got new errors and clean failure now. | 21:44 |
| satoshi | https://www.irccloud.com/pastebin/TDSZOR2D/ | 21:44 |
| JayF | clean failing when container failed is an improvement \o/ | 21:44 |
| JayF | [ 183.514892] ironic-python-agent[534]: Stderr: 'Error: OCI runtime error: crun: pivot_root: Invalid argument\n': oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. | 21:45 |
| JayF | that's a fun one | 21:45 |
| JayF | I am generally unfamiliar with this error and we'll have to dig | 21:45 |
| JayF | I'm surprised it didn't just work | 21:45 |
| cardoe | JayF: ah so I see the conductor is gonna call the agent's URL and pass the configdrive info that way. | 21:49 |
| satoshi | Yeah, sure. I will research it some more. | 21:50 |
| JayF | https://forum.tinycorelinux.net/index.php/topic,21089.0.html | 21:50 |
| JayF | satoshi: ^ basically it sounds like it's trying to pivot_root which is completely forboden (today I learned) inside a ramdisk | 21:51 |
| JayF | there might be a way to disable pivot root | 21:51 |
| JayF | the answer in 2017 was DOCKER_RAMDISK=true in the dockerd spawn | 21:51 |
| JayF | but there's likely amore generic way now | 21:51 |
| cardoe | What I'm trying to do now is download the instance_metadata / configdrive and parse the network_data.json to setup the network before rebooting out of their installer. | 21:52 |
| cardoe | But otherwise this works with very minimal Ironic tweaks. | 21:53 |
| JayF | yeah I figured all the framing was there for it | 21:53 |
| JayF | just a matter of reassembling context on what goes where | 21:53 |
| cardoe | Well most of the fixes are to make the anaconda deploy interface actually work again | 21:58 |
| opendevreview | Steve Baker proposed openstack/ironic master: Add systemd provider for console containers https://review.opendev.org/c/openstack/ironic/+/941614 | 22:08 |
| opendevreview | Steve Baker proposed openstack/ironic master: Implement drivers redfish-graphical, fake-graphical https://review.opendev.org/c/openstack/ironic/+/941615 | 22:08 |
| opendevreview | Steve Baker proposed openstack/ironic master: Add vnc-container image build https://review.opendev.org/c/openstack/ironic/+/942017 | 22:08 |
| opendevreview | Steve Baker proposed openstack/ironic master: Implement graphical console read-only support https://review.opendev.org/c/openstack/ironic/+/942300 | 22:08 |
| opendevreview | Steve Baker proposed openstack/ironic master: Fix default IRONIC_DEFAULT_TRAITS setting https://review.opendev.org/c/openstack/ironic/+/942647 | 22:08 |
| stevebaker[m] | I'm going to need that fix from vsaienko for nova vnc console to work | 22:13 |
| cardoe | https://www.irccloud.com/pastebin/j6SlKIMJ/ | 22:15 |
| cardoe | JayF: ^ isn't that what you were hitting? | 22:15 |
| JayF | is one of the images in your flow | 22:15 |
| JayF | not public? | 22:15 |
| JayF | if so, yes potentially | 22:15 |
| JayF | see https://bugs.launchpad.net/ironic/+bug/2099276 | 22:15 |
| JayF | which lays out the flow | 22:16 |
| cardoe | So the weird thing there... the machine stayed in "wait call-back" the entire time the installer ran. Only when the installer finished did it switch to deploying. | 22:20 |
| cardoe | My images are "shared", which is what the Anaconda docs say they need to do. | 22:21 |
| JayF | the anaconda docs are wrong | 22:21 |
| JayF | they need to be public | 22:22 |
| JayF | it all uses the same authorization code now | 22:22 |
| * JayF suspects that doc was written against a purple! fork | 22:22 | |
| cardoe | I've got a pile of notes that are gonna go into a doc update. | 22:28 |
| cardoe | But first I wanna get this to work once. | 22:28 |
| JayF | well | 22:28 |
| JayF | bug 2099276 aims to make the doc right | 22:28 |
| JayF | lol | 22:28 |
| JayF | we said, in there, we wanted to open it to shared, not just public | 22:28 |
| cardoe | I honestly think we should remove the kickstart template from shipping as part of Ironic. | 22:28 |
| JayF | given the authorization model for glance with shared is basically "do you know the uuid?" | 22:28 |
| JayF | my impression is that it's intended as much as an example as a drop-in | 22:29 |
| JayF | it used to be more common for us to have files like that, e.g. the pxe config template | 22:29 |
| cardoe | Yes. But I think you're gonna want it to be a per-image thing. | 22:29 |
| cardoe | The only time it makes sense to have a global one is if you're deploying the same distro in 6 different flavors. | 22:29 |
| JayF | What information would ironic have to make a per-image decision? | 22:29 |
| cardoe | None. But you need to customize it per distro. | 22:30 |
| JayF | oh, you can pass a different ks template, I believe, yeah? | 22:30 |
| JayF | and I think some of that metadata is in image_info | 22:30 |
| cardoe | On a per image basis or a global Ironic one. | 22:30 |
| JayF | ^^^ if it's in image_info, it's in glance riding along with the image | 22:30 |
| JayF | but I may not fully remember all the moving parts | 22:30 |
| cardoe | It is. | 22:30 |
| cardoe | I'm uploading my own ks_template to glance. | 22:31 |
| JayF | I'll note this interface has a long-standing feature request from cern to allow user templates | 22:31 |
| cardoe | But I'm saying Ironic shipping a "global" default is likely wrong. | 22:31 |
| cardoe | Got a link to the feature request? | 22:31 |
| JayF | I don't know if it's bugged, but it's been discussed nearly anytime I meet them in person | 22:31 |
| JayF | I think we go "how do we pipe that through nova" and the conversation goes down the pipe | 22:31 |
| cardoe | I've already got an idea how to do it with a cloud-init style user_data | 22:32 |
| JayF | I'd suggest writing the flow down and getting nova and ironic folks to review it before you get too far down the path | 22:32 |
| JayF | if you want it to be upstreamable | 22:32 |
| cardoe | So I think we bumped from "testing" (which is non-voting) from CentOS 7/8 to CentOS 9. We're using the ks_template that's baked into Ironic. But that template won't work with 9. | 22:32 |
| JayF | and nowish is the right time to start motion on that | 22:32 |
| cardoe | That's why I'm saying shipping the template is wrong. | 22:33 |
| cardoe | I'll write down the flow once I get it to work correctly once. :D | 22:34 |
| cardoe | https://opendev.org/openstack/ironic/src/commit/b44cce176fbb8c81c813304cd443d0f2c20ab6b2/ironic/common/kickstart_utils.py#L127-L141 | 22:34 |
| JayF | that code is the primary reason this is anaconda-coded instead of being generic | 22:35 |
| cardoe | https://opendev.org/openstack/ironic/src/commit/b44cce176fbb8c81c813304cd443d0f2c20ab6b2/ironic/common/kickstart_utils.py#L147 | 22:35 |
| cardoe | Yeah except it's coded against a specific anaconda. | 22:35 |
| cardoe | RHEL != Fedora as well. | 22:35 |
| cardoe | The hardcoded path won't work against CentOS 9, cause I tried just to see what the data was like. | 22:36 |
| JayF | I mean, you're right, but you're also essentially trailblazing. AFAIK, this driver has been used by two ironic-contributing places in total: yahoo (who wrote it downstream + upstreamed this improved version of it), and cern | 22:36 |
| cardoe | I'll fix it. It'll be my pile of yaks to fix. | 22:37 |
| cardoe | I wanted to work on inspection and redfish but this will have to do. | 22:37 |
| JayF | Yeah. I already had to fight off the city once, I'm not zoned to have this large of a yak stack | 22:38 |
| opendevreview | Doug Goldstein proposed openstack/ironic master: fix glance metadata layout https://review.opendev.org/c/openstack/ironic/+/942496 | 23:36 |
| cardoe | I've created https://bugs.launchpad.net/ironic/+bug/2099953 and updated the commit message to say that fixes that. | 23:37 |
| JayF | cardoe: we need a release note for backportable patches to be backported | 23:38 |
| cardoe | https://bugs.launchpad.net/ironic/+bug/2099275 is my bug for the follow on work to make this more robust. | 23:38 |
| cardoe | okay I'll add a release note. | 23:38 |
| JayF | the bug note in commit should be useful for future devs \o/ | 23:38 |
| * JayF & | 23:41 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!