| rpittau | good morning ironic! o/ | 08:08 |
|---|---|---|
| masghar | Good morning! | 09:10 |
| opendevreview | Merged openstack/bifrost stable/victoria: CI: Update cached cirros image to 0.5.3 https://review.opendev.org/c/openstack/bifrost/+/885880 | 09:58 |
| iurygregory | good morning Ironic | 11:08 |
| TheJulia | good morning | 12:52 |
| iurygregory | good morning TheJulia =) | 12:59 |
| JayF | Did anyone else want in on an Ironic docs meeting? Trying to come up with a plan of work that my downstream might try to get some resources to implement fo rus | 14:53 |
| JayF | When I asked before Dmitry was the only one that responded IIRC; just ensuring nobody else is interested before sending invites | 14:53 |
| iurygregory | JayF, please add me =) | 14:54 |
| JayF | ack; I'm assuming early PST (this time of day +2-3 hours?) works for you? | 14:54 |
| iurygregory | yup | 14:56 |
| JayF | #startmeeting ironic | 15:00 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'ironic' | 15:00 |
| JayF | Hey guess what; another meeting! | 15:00 |
| JayF | #topic Announcements/Reminder | 15:00 |
| TheJulia | o/ | 15:00 |
| 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 |
| iurygregory | o/ | 15:00 |
| JayF | #topic Review action items from previous meeting | 15:00 |
| JayF | #info JayF to backport ngs_save fix for networking_generic_swtich, cut a bugfix-version (not branch) release of it | 15:01 |
| JayF | going to be honest, don't remember if I did this, checking | 15:01 |
| rpittau | o/ | 15:01 |
| iurygregory | you did | 15:01 |
| JayF | did it land? | 15:01 |
| iurygregory | just need to update based on the reivew | 15:01 |
| rpittau | JayF: re ironic docs: I think I replied too, or maybe not :P | 15:01 |
| JayF | rpittau: ack, will add you to the meeting, I thought I missed someone | 15:01 |
| JayF | rpittau: my IRC "highlights channel" is unreadable after the last week, for some reason :D | 15:02 |
| JayF | iurygregory: I'll follow up on it | 15:02 |
| JayF | #topic Caracal release Schedule | 15:02 |
| rpittau | :D | 15:02 |
| JayF | #link https://releases.openstack.org/caracal/schedule.html | 15:02 |
| 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:02 |
| JayF | I doubt there's action for us to take this week for release in October :D | 15:03 |
| JayF | #topic PTG Review | 15:03 |
| JayF | #link https://etherpad.opendev.org/p/ironic-ptg-october-2023 | 15:03 |
| 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 |
| JayF | I wanna track any "JFDI" level items here | 15:03 |
| JayF | Actually; brakes and reverse: I don't want to take this for granted; thank you all for participating in vPTG last week | 15:04 |
| 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 |
| 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 |
| JayF | #undo | 15:05 |
| 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 |
| 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:05 |
| 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 |
| 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 |
| JayF | #action JayF [from PTG] Setup IPA-builder in launchpad | 15:06 |
| TheJulia | ... do we have periodics? | 15:07 |
| JayF | all stable jobs run in periodics aiui | 15:07 |
| JayF | #action masghar [from PTG] provide feedback about specific gaps in documentation, fix if small, provide feedback if more sizable | 15:08 |
| TheJulia | .. That doesn't seem right, but it could still be done and not obvious with the config | 15:08 |
| 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 |
| JayF | TheJulia: either way; I'll dig as part of doign it | 15:08 |
| 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 |
| JayF | that's tuesday LOL | 15:09 |
| JayF | #action JayF [from PTG] email list about IntelIPMIManagement driver usage | 15:09 |
| JayF | I don't see explicit actions bolded out of OVN/Redfish, TheJulia were there any? | 15:10 |
| JayF | looks like maybe just make 3 bugs are the only actions there? | 15:10 |
| TheJulia | JayF: None from OVN, it was more information/context setting | 15:10 |
| TheJulia | Redfish, Let me glance again | 15:10 |
| JayF | I think that's all the "small" actions AFAICT | 15:11 |
| JayF | everything else is large enough to need a bug or to be in a workstream | 15:11 |
| 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 |
| 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:11 |
| JayF | Oh, there is one other action not to drop | 15:12 |
| TheJulia | Also, RFE for boot status, but nothing major really | 15:12 |
| TheJulia | small building blocks | 15:12 |
| JayF | #action JayF Book a meeting with stakeholders; TheJulia JayF and johnthetubaguy minimum, on Nova driver bug fixing/hunting | 15:13 |
| JayF | If anyone wants in on that, please ask; only reason we didn't PTG it was so we'd be fresher :) | 15:13 |
| JayF | Alright, anything else as follow-up to PTG before we move on? | 15:14 |
| JayF | #topic Review Ironic CI Status | 15:14 |
| 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:15 |
| rpittau | haven't seen any p[articular recurring or worrying failure since a while | 15:16 |
| JayF | #topic RFE Review | 15:16 |
| JayF | there's one up for review | 15:16 |
| JayF | #link https://bugs.launchpad.net/ironic/+bug/2040236 | 15:16 |
| JayF | Reading this RFE, I'm not sure I want to approve it as written. | 15:17 |
| JayF | The bug itself implies that it might add the config and only implement it for iRMC | 15:17 |
| JayF | if we add a config under `[conductor]` to set that path, it needs to be respected throughout | 15:18 |
| 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 |
| JayF | Just seems like there's enough edges there that an RFE bug might not be sufficient. | 15:18 |
| JayF | WDYT? | 15:18 |
| TheJulia | so... I guess I'm conflicted | 15:18 |
| TheJulia | because verify_ca is supposed to take a path out of the box | 15:19 |
| JayF | If it was like, [irmc]irmc_default_verify_ca_path | 15:19 |
| TheJulia | I guess I don't understand *why* from the lp bug | 15:19 |
| JayF | I'll comment in there, saying we were unable to approve because the scope and the "why" is unclear | 15:20 |
| TheJulia | Why do we need a second level default | 15:20 |
| 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 |
| 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 |
| JayF | of course :) | 15:20 |
| iurygregory | and take async | 15:20 |
| TheJulia | looks like they also want to add it as a node field | 15:20 |
| TheJulia | which is... semi-problematic | 15:21 |
| JayF | Yeah, we can't have that as a per-node override. | 15:21 |
| TheJulia | not insurmountable, but yeah, better understanding of need is needed | 15:21 |
| 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 |
| TheJulia | but then that requires you know internal details like location of files on disk and set/get that via an API | 15:22 |
| JayF | [agent]verify_ca exists | 15:22 |
| JayF | so does [ilo]verify_ca | 15:22 |
| JayF | but nothing condcuctor-wide | 15:22 |
| TheJulia | yeah, this is driver level for speaking with the remote BMC | 15:23 |
| JayF | OK; so I think we need to needs-spec this then, if it's node level | 15:23 |
| JayF | because we need to be very explicit about how we RBAC a setting to change the verify_ca settings per node | 15:23 |
| JayF | Do you think that's overkill? | 15:24 |
| TheJulia | RBAC wies, it would just need to be adminy user | 15:24 |
| TheJulia | wise | 15:24 |
| TheJulia | From a what is in the field wise, it really can't be a file path | 15:24 |
| TheJulia | which makes this further challenging | 15:25 |
| JayF | Why not? You'd expect the deployment tooling to do key management. | 15:25 |
| TheJulia | Think user not having filesystem access to the remote server where Ironic is running | 15:25 |
| TheJulia | they don't *actually* know where the files are for that CA | 15:25 |
| 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 |
| TheJulia | best they can supply, realistically, is a URL | 15:25 |
| JayF | oh, CA is not a private key | 15:25 |
| JayF | it's a public key | 15:25 |
| TheJulia | correct | 15:26 |
| TheJulia | but they want to provide paths | 15:26 |
| JayF | but URL is still not ideal, because you can't trust that value is the same | 15:26 |
| * drannou has done his homework, when you want to speak about RFE #2039676 | 15:26 | |
| JayF | this needs to be specced. | 15:26 |
| TheJulia | JayF: yeah, basically it does need to be written up in a more verbose form | 15:26 |
| TheJulia | I get their basic intention after skimming the openshift enhancement doc | 15:26 |
| TheJulia | and after you looked at the config, we just need to find a sensible path forward | 15:27 |
| JayF | commented, tagged needs-spec | 15:28 |
| JayF | drannou: that was not on the agenda | 15:28 |
| JayF | drannou: usually we prefer those be on the agenda first | 15:28 |
| JayF | but I'm curious :) | 15:28 |
| drannou | no problem, we can discuss about it when you want | 15:29 |
| 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 |
| JayF | a feature of that bulk is going to need a spec | 15:29 |
| 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 |
| 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 |
| JayF | but given it'll change deployment flows that'll help us understand exactly how | 15:30 |
| TheJulia | I think this could just be a specific deploy interface, tbh, but those sorts of questions need to be sorted through | 15:31 |
| JayF | the why honestly is really important | 15:31 |
| JayF | bceause if we know why we can help more with the how :D | 15:32 |
| drannou | For me it's a new driver, that is impacting deploy interface, reboot, etc | 15:32 |
| drannou | Why activating this feature ? | 15:32 |
| 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 |
| TheJulia | drannou: paint the vision for us, although I do seriously think a spec document is in your future :) | 15:32 |
| 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 |
| TheJulia | (we do require such when we start talking adding interfaces/drivers, fwiw) | 15:33 |
| TheJulia | Ahh, okay. | 15:33 |
| 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:33 |
| TheJulia | tons, in the opendev.org/openstack/ironic-specs repo, there is also a template to start from | 15:34 |
| JayF | Oh, there is a spec template, and it is glorious. | 15:34 |
| 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 |
| drannou | Wonderfull, I will check that and try to do it tomorrow | 15:34 |
| JayF | thanks! | 15:35 |
| drannou | Do you need more context on why we need SED exactly ? | 15:35 |
| JayF | Yes, exactly | 15:35 |
| JayF | we want the use case | 15:35 |
| JayF | tell us the problem you have, how this solves it | 15:35 |
| JayF | why SED managed by the OS doesn't solve it | 15:35 |
| TheJulia | and the why which drives the pattern of offloading the host OS awareness of SED | 15:35 |
| JayF | honestly, doesn't even matter so much if we have the use case, think it's valuable, etc | 15:36 |
| 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 |
| 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 |
| TheJulia | oh | 15:36 |
| JayF | Ah, so one of the key requirements here is that the customer holds the key | 15:36 |
| TheJulia | such that the machine can't independently boot | 15:36 |
| TheJulia | ugh | 15:36 |
| drannou | exactly | 15:37 |
| TheJulia | drannou: please include links to the regulation | 15:37 |
| drannou | ok | 15:37 |
| TheJulia | I suspect we have some reading we'll need to do | 15:37 |
| JayF | this is something that would likely need like | 15:37 |
| JayF | console or something like that | 15:37 |
| JayF | dang | 15:37 |
| 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:37 |
| JayF | how do you do this without the cloud provider being able to intercept? | 15:38 |
| TheJulia | Lots, and lots of layers of trust to establish | 15:38 |
| JayF | even if you used console and put in key that way, you can proxy it | 15:38 |
| JayF | This is a good use case, valuable. | 15:38 |
| JayF | Also impossible-sounding. | 15:38 |
| JayF | I'm glad it's your use case and not mine drannou ;) | 15:38 |
| 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 |
| TheJulia | eh, nothing is impossible, just depends on the size of the lever | 15:39 |
| JayF | Aight, I think we have a decent idea | 15:39 |
| JayF | drannou: this all still has to be written down btw | 15:39 |
| JayF | going to move on to... | 15:39 |
| JayF | #topic Open Discussion | 15:40 |
| JayF | Anything else? | 15:40 |
| drannou | https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/898723 | 15:40 |
| 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 |
| drannou | I have this PR that is waiting for reviews, and may be even a global discussion for your question JayF | 15:40 |
| JayF | yeah I just refreshed my comment and -1 | 15:41 |
| TheJulia | In other news, I have written the first recipe down into a gdoc. | 15:41 |
| drannou | (Question arround DHCP on IPA) | 15:41 |
| JayF | Thanks drannou; hopefully folks have a look. I suspect reviews will start back up this week as people recover from PTG. | 15:42 |
| drannou | Ok wonderfull thx | 15:42 |
| JayF | last call before I close the meeting? | 15:43 |
| TheJulia | JayF: just commented | 15:43 |
| JayF | #endmeeting | 15:44 |
| opendevmeet | Meeting ended Mon Oct 30 15:44:03 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:44 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-10-30-15.00.html | 15:44 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-10-30-15.00.txt | 15:44 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-10-30-15.00.log.html | 15:44 |
| TheJulia | I've sort of mixed on that change specifically, but start state config is a hard problem (else this wouldn't be week 3 staring at it) | 15:44 |
| JayF | TheJulia: that is ~what I suspected but didn't want to +2 based on an assumption | 15:44 |
| masghar | Very late to the party, apologies. JayF: I have a small document here with respect to Bifrost docs, if we could have similar added to the docs it would be great: https://docs.google.com/document/d/1BlvJNL-wmqQIhKN1Yn0XHeanY53mOrzDHdSutzxjabI/edit | 15:45 |
| JayF | masghar: can you make that readable to all? | 15:47 |
| JayF | masghar: if not will dm you list to open it to | 15:47 |
| masghar | Oh of course! | 15:47 |
| masghar | I have MACs and IPs mentioned in the diagrams. Is that alright? (I can change it afterwards if its okay) | 15:48 |
| JayF | I don't mind that; but if it's private informatino you likely want to change it before sending it to me :) | 15:49 |
| JayF | I don't want any secrets | 15:49 |
| masghar | I am not entirely sure, let me try to sanitize it a bit, make sure, and will make it readable to all | 15:49 |
| rpittau | masghar: probably better do an upstream public version with no info | 15:49 |
| masghar | rpittau, ack | 15:50 |
| JayF | https://docs.openstack.org/ironic/latest/admin/drivers/snmp.html#software-requirements needs a fix | 16:27 |
| JayF | > The PySNMP package must be installed, variously referred to as pysnmp or python-pysnmp | 16:28 |
| JayF | we're using a different ecosystem now, I think. | 16:28 |
| rpittau | JayF: yes, that would be pysnmp-lextudio | 16:46 |
| JayF | rpittau: yeah, probably the better fix it "install driver-requirements.txt" | 16:46 |
| JayF | rpittau: I just wanted to comment it here because Is aw it and couldn't fix it r/n | 16:46 |
| JayF | I'll probably do a quickfix before eod if nobody else does | 16:47 |
| opendevreview | Jay Faulkner proposed openstack/ironic master: Remove outdated pysnmp reference https://review.opendev.org/c/openstack/ironic/+/899624 | 17:01 |
| rpittau | good night! o/ | 17:03 |
| opendevreview | Jay Faulkner proposed openstack/ironic master: Remove outdated pysnmp reference https://review.opendev.org/c/openstack/ironic/+/899624 | 17:05 |
| TheJulia | dtantsur: https://bugs.launchpad.net/ironic/+bug/2041901 as a follow-up from the ptg | 17:25 |
| dtantsur | Thanks! I wonder if we should default to removing the UEFI records if the disk is cleaned | 17:26 |
| dtantsur | These operations are not orthogonal | 17:27 |
| dtantsur | (although I do see value in a separate step as well) | 17:27 |
| JayF | eh, it's weird right | 17:29 |
| JayF | like, if we wanted to tie it to disk eraasure, that's an interesting idea | 17:30 |
| JayF | but problematic as well | 17:30 |
| JayF | because we don't want operators to have to udpate all custom disk erase steps to be uefi aware | 17:30 |
| JayF | and we'd have to do such a disk-tied implementation as single-disk-aware so we'd only wipe the entries for the disks that were getting wiped | 17:30 |
| JayF | and it gets even *more* complex if you have a software raid root | 17:30 |
| JayF | so I think a separate step just gets us away from all those edges | 17:31 |
| dtantsur | In the presence of disks that are NOT cleaned, we cannot also clean UEFI records. Who knows why these partitions are not cleaned, it could be OS recovery or some vendor tools. | 17:31 |
| JayF | yes-ish, but I also would propose we won't always have the information we need to make those decisions | 17:34 |
| dtantsur | That's why I wonder if we need two things: a more aggressive clean step that removes everything we don't like and a more gentle part of the erase_* that only removes entries related to the disks being erased | 17:36 |
| JayF | so like, erase_block_devices becomes a dispatcher that, for each device; do: | 17:36 |
| JayF | erase_uefi_boot_for_block_device | 17:36 |
| JayF | erase_block_device | 17:36 |
| JayF | device_smart_status | 17:37 |
| JayF | something_else_i_cant_think_ofper_block_device | 17:37 |
| JayF | I still worry about having enough information | 17:37 |
| JayF | IMO; Julia's proposal represents an MVP (even if it would be disabled by default due to your concerns) | 17:38 |
| JayF | your proposal represents the next enahncement to something like that | 17:38 |
| dtantsur | Yeah, it makes sense as an MVP | 17:38 |
| TheJulia | I was sort of having the same inner discussion as I was writing the bug, and my mind leaned towards "nuke everything" and ask for forgivness later from nvram. I mean, we could likely figure out and map things, but my worry is also devices where we can't | 17:41 |
| * TheJulia looks at Emulex FC adapters with her best corgi impression | 17:42 | |
| JayF | TheJulia: is there any way to back this information up to the EFI partition, I wonder? | 17:43 |
| JayF | That gets ... sticky and maybe outta ironic scope a little | 17:43 |
| JayF | or maybe even just log it in enough detail to recreate if you have access to the cleaning logs | 17:43 |
| TheJulia | I honestly kind of think we could find it happy as-is and backport if we really wanted to, or not. This is one of those things we've gone back and forth on since it is a bug at the end of the day | 17:43 |
| TheJulia | Yeah, we can log it | 17:44 |
| JayF | I think there's a specific use case this is brutal to, in terms of how it's bugged | 17:44 |
| JayF | but I think it's potentially brutal to the flip side use case | 17:44 |
| JayF | where someone is using Ironic to provision to a machine once and leave it alone | 17:44 |
| JayF | and may not expect things like, as dtantsur mentions, vendor tools and such to disappear from EFI menus | 17:44 |
| TheJulia | Arne did the pram stuffs as well, which is semi related, but there is the "there is a OS recovery image in the BMC" aspect which is a whole curve ball, but really that should *not* be UEFI addressed under normal cirumstances | 17:44 |
| TheJulia | And... those special records are like FSVAR labels instead of HD labels | 17:45 |
| JayF | that is part of what hurts here, it's that the rare cases this could cause pain on are almost the exact opposite set from the folks that benefit | 17:45 |
| JayF | at least in my estimation | 17:45 |
| TheJulia | so, vendor tools *should not* be on the disks, under normal cirumstances. | 17:45 |
| TheJulia | That being said, the image inside the BMC thing, we've seen that with the fsvar label | 17:46 |
| TheJulia | those we would likely just ignroe | 17:46 |
| TheJulia | ... someone, hwoever writes the patch, needs to go dig at the e2dk nvram labels | 17:46 |
| TheJulia | since there is a meaning there that we can only guess about too | 17:47 |
| JayF | access to a handful of different hardwares would remove a lot of unknowns from this | 17:47 |
| JayF | or at least, getting output from a command from them would... | 17:47 |
| TheJulia | Dell is definitely like fsvar(stuff):/path/file | 17:47 |
| * JayF adds ironic-etd to phone home /s /s /s | 17:47 | |
| TheJulia | Anyone got a freshish ilo machine with the efibootmgr output handy? | 17:48 |
| JayF | What command will you need run? I can ask my downstream but it would likely be a long turnaround if they got it | 17:49 |
| TheJulia | "efibootmgr -v" | 17:49 |
| TheJulia | It will include some UUIDs and labeles, so maybe a little redaction or modification might be the needful | 17:50 |
| TheJulia | Network devices are typically PciRoot devices too | 17:50 |
| TheJulia | https://www.irccloud.com/pastebin/HTgnfpbF/ | 17:51 |
| TheJulia | That is my desktop | 17:51 |
| JayF | ack; I passed on the ask. I know they are crushed right now through EOY and this is low priority, but if they're able to they will. | 17:52 |
| JayF | We could also email nisha's team to get info for at least the lines they work on. | 17:52 |
| TheJulia | ++ | 17:52 |
| TheJulia | Nisha did add a sushy bug we could use insight on | 17:52 |
| JayF | (well, not low priority for you, I know, but upstream is lower priority than the work they are doing I mean :D) | 17:52 |
| TheJulia | apparently a string we're looking for in the bmc response is an internal version id that leaks | 17:53 |
| TheJulia | well, it might just be the OS version | 17:53 |
| TheJulia | but yeah..... | 17:53 |
| JayF | I'm out today in about an hour, heads up; gotta take the kitty to the vet | 18:08 |
| TheJulia | lk | 18:09 |
| TheJulia | err, ok | 18:09 |
| JayF | Also will not be in IRC at all Friday; will be at SeaGL conference Fri/Sat in Seattle. | 18:09 |
| JayF | I will have socks! Tell people to come to my talk and get some. | 18:09 |
| TheJulia | sadly the demise of twitter has largely disconnected me from most of those folks :( | 18:17 |
| iurygregory | JayF, can you convert your +1 to +2 in https://review.opendev.org/c/openstack/ironic/+/897989 ? | 21:52 |
| iurygregory | and +W =) since we have +2 from dtantsur | 21:53 |
| JayF | Julia has a comment on that she hasn't ack'd your response to | 22:29 |
| JayF | that's the sorta thing I'd rather wait on or let another core ack who knows the hardware and has more confidence | 22:29 |
| TheJulia | I just reviewed it, thanks iurygregory | 22:31 |
| JayF | \o | 22:32 |
| JayF | / | 22:32 |
| iurygregory | oh, tks eveyrone | 22:51 |
| iurygregory | tomorrow will be complicated since I need this downstream for a escalation YAY | 22:51 |
| opendevreview | Merged openstack/ironic master: Make sure we eject media from DVD when CD is requested https://review.opendev.org/c/openstack/ironic/+/897989 | 23:34 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic stable/2023.2: Make sure we eject media from DVD when CD is requested https://review.opendev.org/c/openstack/ironic/+/899335 | 23:44 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic bugfix/22.1: Make sure we eject media from DVD when CD is requested https://review.opendev.org/c/openstack/ironic/+/899336 | 23:44 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic bugfix/22.0: Make sure we eject media from DVD when CD is requested https://review.opendev.org/c/openstack/ironic/+/899337 | 23:44 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic stable/2023.1: Make sure we eject media from DVD when CD is requested https://review.opendev.org/c/openstack/ironic/+/899338 | 23:44 |
| opendevreview | Julia Kreger proposed openstack/ironic-tempest-plugin master: WIP: Add test for dhcp-less vmedia based deployment https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/898006 | 23:56 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP/DNM: Advanced vmedia deployment test ops https://review.opendev.org/c/openstack/ironic/+/898010 | 23:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!