Monday, 2024-08-05

rpittaugood morning ironic! o/07:07
adam-metal3good morning ironic! o/07:25
opendevreviewRiccardo Pittau proposed openstack/bifrost master: Remove unused get_md5  https://review.opendev.org/c/openstack/bifrost/+/92566907:53
opendevreviewRiccardo Pittau proposed openstack/bifrost master: Remove unused get_md5  https://review.opendev.org/c/openstack/bifrost/+/92566907:54
opendevreviewRiccardo Pittau proposed openstack/bifrost master: Uplift default Ansible version to 9.x  https://review.opendev.org/c/openstack/bifrost/+/92556307:54
ContinuityAh no worries TheJulia. Im around most of the time as you have seen :D08:03
opendevreviewDmitry Tantsur proposed openstack/ironic master: DevStack: enable the new in-band inspection by default  https://review.opendev.org/c/openstack/ironic/+/92568811:29
opendevreviewcid proposed openstack/ironic master: [WIP] docs-audit-2024: Labeling references  https://review.opendev.org/c/openstack/ironic/+/92569112:24
opendevreviewcid proposed openstack/ironic master: [WIP] docs-audit-2024: Use a description for concept headings  https://review.opendev.org/c/openstack/ironic/+/92569212:24
opendevreviewcid proposed openstack/ironic master: [WIP] docs-audit-2024: Use gerunds for task headings  https://review.opendev.org/c/openstack/ironic/+/92512912:25
TheJuliagood morning13:21
opendevreviewAdam Rozman proposed openstack/ironic master: implement custom reboot support  https://review.opendev.org/c/openstack/ironic/+/92570313:24
adam-metal3Just a heads up. I have proposed discussion topics related to 3 RFEs for today's meeting, All three are in different stages of implementation and I am working/worked on them (there is one that is already done). 13:37
TheJuliaadam-metal3: So, a property available to steps on the first item, not a distinct step right? I first read it as a new step, so just want to be clear.14:22
adam-metal3TheJulia: it is just a new property not a new step14:24
TheJuliaack, cool cool14:24
TheJuliayour first two rfes, at least lgtm14:24
TheJuliayour 2nd might just be a bug depending on point of view14:24
TheJuliaI need more cofffeeeeeee for the third14:24
adam-metal3TheJulia: Thanks for the feedback!14:30
dtantsuradam-metal3: I'm not sure I understand what the custom reboot should do.. do you want to stay in IPA instead of getting into your instance?14:33
dtantsurthis RFE could use a user story explained14:34
adam-metal3dtantsur: main goal is to just make Ironic not bother with managing the reboot because there won't be any reboot for a potentially long period of time or the reboot will be handed over to some other process running in the IPA , I would like to simply allow the IPA customization to take care of the reboot process. 14:37
adam-metal3mayb do systemd re initialization or kernel swapping or something that is not part of the regural workflow and might even turns the IPA off14:39
adam-metal3I will add a few of these examples14:45
dtantsuradam-metal3: the second example is what I'm quite worried about: you cannot do a clean reboot without Ironic orchestrating it. Think of all the things that Ironic needs to clean up: virtual media devices, PXE settings, boot device in the BMC, potentially more in the future.14:53
adam-metal3dtantsur: yeah I understand that but that is the responsibility of whoever custimizes the IPA IMO, if someone is willing to write custom hardware manager and use custom IPA that person should be aware that this is a custom workflow 14:54
adam-metal3and ask for a custom reboot process14:55
dtantsurThis sounds like a new API feature for a very exotic case. Can it be a config option instead? A custom deploy step downstream?14:55
adam-metal3it can't because even if I use custom deploy step Ironic will restart the machine and I would like to avoid that, 14:56
dtantsurA configuration option maybe?14:56
JayFThis is honestly something that even if we did, we might wanna hide in e.g. custom-agent driver14:56
dtantsurI'm thinking how to avoid an API flag that will break things for 99.9% of users14:57
dtantsur(if they try to use it, of course)14:57
JayFI am sorta -.5 to it right now, worried it'll be like [agent]/manage_agent_boot where it's unsupported, and mostly useless, but we have to deprecate it now14:57
JayFand serves a single weirdo use case14:57
* TheJulia blinks14:57
dtantsurOh, hmm, if it's only for custom-agent and is inside driver_info.. I can live with it, I guess14:57
adam-metal3So this would be a property of the step implemented in the custom hrdware manager, no config option needed, no one would need to even think about it unless developing a custom hardware manager14:58
TheJuliadtantsur: that was the way I was reading it14:58
TheJuliabut would be good to be slightly more specific14:58
dtantsuradam-metal3: I might have misread the RFE a bit. So it's not exposed in the API?14:58
TheJuliaI was thinking it would be something the overall context would be determined through the runtime of the custom agent14:59
JayFreboot is not a step; that's the thing14:59
JayFreboot is like, 14 steps14:59
TheJuliaYeah14:59
TheJuliafor ironic, it is14:59
adam-metal3it is not part of the reboot14:59
JayFand it seems to me we'd have to break it up, aka deploy steps, in order to allow the customization14:59
TheJuliaand removing it by any default begins to tear down the security barrier we lay down14:59
TheJuliamight be better as a high bandwidth discussion, fwiw14:59
TheJulia(since we're all got different reads of it)14:59
TheJuliawe've14:59
* TheJulia makes coffee15:00
rpittauright in time!15:00
rpittau#startmeeting ironic15:00
opendevmeetMeeting started Mon Aug  5 15:00:14 2024 UTC and is due to finish in 60 minutes.  The chair is rpittau. Information about MeetBot at http://wiki.debian.org/MeetBot.15:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'ironic'15:00
masgharo/15:00
TheJuliao/15:00
adam-metal3o/15:00
rpittauHello everyone!15:00
rpittauWelcome to our weekly meeting!15:00
rpittauThe meeting agenda can be found here:15:00
rpittau#link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_August_05.2C_202415:00
cido/15:00
dtantsuro/15:00
rpittau#topic Announcements/Reminders15:01
rpittauStanding reminder to review patches tagged ironic-week-prio and to hashtag any patches ready for review with ironic-week-prio15:01
rpittau#link https://tinyurl.com/ironic-weekly-prio-dash15:01
iurygregoryo/15:02
rpittauwe have some patches in merge conflict in the list, worth having a look there15:02
rpittau#info 2024.2 Dalmatian Release Schedule15:03
rpittau#link https://releases.openstack.org/dalmatian/schedule.html15:03
opendevreviewMaryna Savchenko proposed openstack/ironic master: Fixes config drive base64 encoding in kickstart file  https://review.opendev.org/c/openstack/ironic/+/92556915:03
rpittauwe're at R-8 two months to go!15:03
TheJuliak, I'll try to rebase those this week15:03
rpittauthanks TheJulia :)15:03
opendevreviewMaryna Savchenko proposed openstack/ironic master: Fixes config drive base64 encoding in kickstart file  https://review.opendev.org/c/openstack/ironic/+/92556915:03
rpittauFeature Freeze is in 3 weeks15:03
JayFI really, really need reviews on ironic-guest-metadata15:04
JayFbecause Nova will enforce FF15:04
iurygregory++15:05
rpittauJayF: I see it's failing CI, unrelated ?15:05
JayFyes15:05
opendevreviewMaryna Savchenko proposed openstack/ironic master: Fixes config drive base64 encoding in kickstart file  https://review.opendev.org/c/openstack/ironic/+/92556915:05
JayFjust not rechecking like a madman on something that almost certainly will get revised15:05
rpittauok15:05
rpittauany other priorities since we're close to FF ?15:06
cidWhat's FF?15:06
rpittauFeature Freeze15:06
cidOh, okay 15:06
cidI'm soliciting reviews on runbooks 15:07
TheJuliaJayF: so you need it merged, what, this week?15:07
TheJuliain ironic/.15:07
TheJulia?15:07
cidAny feedback is appreciated 15:07
JayFTheJulia: I need feedback on the Ironic and Nova changes, and I will ask Nova for nova side reviews15:07
JayFTheJulia: the feature basically straddles both projects so I see it as a situation where both should be +2 before either lands15:08
TheJuliaJayF: if you can post a link, don't know if that is a topic or hashtag15:08
masgharI cant find it in the weekly priorities patches15:08
rpittau#link https://review.opendev.org/c/openstack/ironic/+/92488715:08
masgharThanks!15:08
JayFTheJulia: https://review.opendev.org/q/topic:%22ironic-guest-metadata%2215:08
iurygregorycid, I will take other look this week, the patch is big, but trill wed I should provide some feedback15:08
cidTks15:09
rpittauok moving on15:09
rpittau#info the next OpenInfra PTG which will take place October 21-25, 2024 virtually! don't forget to register15:10
rpittauadd your name and topics to the etherpad15:10
rpittau#link https://etherpad.opendev.org/p/ironic-ptg-october-202415:10
TheJuliaJayF: thanks15:10
rpittauwe'll have to decide the schedule soon so please add your topics there15:10
rpittaubtw I forgot one very important thing!15:11
rpittau#info PTL elections nominations open next week!15:11
rpittau#link https://releases.openstack.org/dalmatian/schedule.html#tc-and-ptl-elections15:12
JayFDo you intend to run again?15:12
rpittauJayF: not sure, I'm still evaluating some things at the moment15:13
TheJuliaplease let us know soon if you decide not to15:14
JayFYeah, someone else has to carve that time out if you don't15:14
cardoeSo I've been nudged to run for TC so I intend on doing that.15:14
rpittauTheJulia: as soon as I know I will let the community know15:15
cardoeI was hoping to land https://review.opendev.org/c/openstack/python-ironicclient/+/924895 into the next client release as well if at all possible.15:16
JayFcardoe didn't even make me get out my cudgel15:16
rpittauonward!15:17
rpittau#topic Review Ironic CI status15:17
rpittauseems like the CI was pretty stable last week15:18
rpittauanything worth mentioning ?15:18
rpittaualright!15:19
rpittau#topic Discussions15:19
TheJuliacardoe: added the ironic-week-prio label to that change15:19
rpittauadam-metal3: you have 3 topics15:19
adam-metal3rpittau: yes15:19
adam-metal3should I go one by one or should I just answer questions?15:20
rpittauadam-metal3: let's do that in order, I think a discussione already started before the meeting15:20
TheJulia+1 to one by one15:21
adam-metal3sure15:21
adam-metal3So the first topic is RFE Ironic Support for custom reboot https://bugs.launchpad.net/ironic/+bug/2076099, https://review.opendev.org/c/openstack/ironic/+/925703  the second link is the implementation15:22
adam-metal3In current implementation of susy tools if you would like to use an OStack VM as to emulate a node with sushy tools but the VM has booted from a volume or a snapshot there will be a failure15:23
dtantsurRe reboot: I've left a comment about using deploy steps overrides - please check15:23
adam-metal3the reason is that sushy tools currently only looks for the boot image that is directly attached to the VM instead of checking the "volume chain" 15:24
JayFI would prefer a route, like Dmitry already posted there, of using existing configs / generic configs to achieve this goal. I am afraid a specific option of this type would be creating technical debt and potentially lead to folks breaking their system if they don't know where all the seams lie.15:24
dtantsurRe sushy-tools: I don't care much about it as long as the implementation is not too crazy to review and maintain15:24
JayFand you can answer "why does this exist" just by reading the repo/docs15:24
JayF(re sushy-tools ^)15:24
cardoePersonally for me I'd rather see 1 path and maybe we fix it with some kind of callback to ensure we're ready to proceed to the next step?15:25
TheJuliare: reboot, I think there is a miss-conveyance of context15:25
adam-metal3oo shit so the first was the reboot15:25
TheJuliabecause the proposal reads as a step, but *not really* based upon the code. Just highlighting as it is a risk to create confusion15:25
adam-metal3sorry sorry for the reboot I have the explanation here:15:25
adam-metal3So RFE 2 custom reboot workflow: dev creates a custom hardware manager, adds "custom_reboot: True" to the step(s)'s proerties (in the code of the custom hardware manage, same as we do for "requires_boot" property) , wehn Ironic reaches this custom step during execution it detects and saved "custom_reboot=true" to the current "Task" instance , when the execution reaches the mandatory "agent_tear_down" out of ban 15:25
adam-metal3step (priority 40) then it checks if the current "Task" have the "custom_reboot" value set to true and if yes it will skip the reboot . TLDR this is an option for those who write custom hardware managers, the proeprty is set during the implementation of the custom steps, no configuration needed during runtime. No exposure of variable on Ironc API , no variable exposure in Ironic or IPA config, all configuartion is 15:25
adam-metal3contained within the custom hardware manager. 15:25
JayFyeah but that's based in a flawed assumption: that the machine, if rebooted in-band, would be able to recover itself15:26
dtantsurWhat I mean is: disabling reboot after deployment is possible now, via deploy steps15:26
JayFhow does Ironic know when to flip the network if I have that enabled?15:26
cardoeSo can you go into what the overall goal is? What's the big overall problem to solve?15:26
JayFthat's why I said earlier that I think the only way this makes sense (outside of the generic route dtantsur already laid out in the bug) is if we make required reboot steps more explicit and documented/overridable in custom-agent similar to how we do required deploy-steps15:27
TheJuliaI suspect this might be a separate case to support, not the default usage case, fwiw15:27
cardoeJayF: yeah that's a question I would have as well. How do it know when to move that.15:27
cardoeexplicit++15:27
TheJuliaThat is sort of critical for those with security boundries to maintain15:27
TheJuliabut maybe custom-agent is not that deployment interface?15:28
dtantsurI guess what we all miss is a pretty detailed user story15:28
cardoe^ agreed15:28
JayFyeah I think something like custom-agent where you are explicitly opting into "Ironic the orchestration engine for me to do deployments in" mode and opting out of "Ironic the deployment tool" mode15:28
TheJuliadtantsur: ++++15:28
dtantsurJayF: this is how we use it in OpenShift, yes15:29
adam-metal3So I would need to provide a user-story, that is fine15:30
TheJuliaAnd I think that is fine, just need to be expressly understood and shared around the differences for interfaces because they all serve different problem spaces15:30
adam-metal3is tehre something else that is an issue ?15:30
dtantsurIt's hard to tell until we know the WHY15:30
TheJuliaadam-metal3: just a statement to set us all to the same context as to how the usage will occur15:30
TheJuliaWe need to be able to answer Why15:30
JayFadam-metal3: I'd say generally we have trepidation for allowing people to override parts of Ironic that can impact the ability for it to work and be secure. That means you gotta tell us a really compelling story as to why it's worth it.15:31
TheJuliaAnd we're all at different starting places with different contexts15:31
TheJuliawhich is why the discussion has headed down the path it has15:32
TheJuliaWe should likely move on to the next item15:32
adam-metal3so the process would be that I write user stories in the RFE and then I bring it up again on the next meeting?15:32
adam-metal3or just on the chat?15:32
rpittauadam-metal3: just on the RFE15:33
JayFand you can always use chats in IRC/meeting to refine if folks are around15:33
TheJuliayeah, on the RFE. Something to help us get to the same place so we unerstand why15:33
TheJuliaJayF: ++15:33
adam-metal3Okay then for the second the sushy tool improvement , do Is is there something I should do there in your opinion ?15:34
JayFcan you link it?15:34
TheJuliaThat reads like a bug to me15:34
rpittauI was thinking the same15:34
TheJulia"I can't use this snapshot which is a registered VM"15:34
adam-metal3Adam] RFE sushy-tools Support for OStack VMs booted from voluem/snapshot https://bugs.launchpad.net/sushy-tools/+bug/2067405, https://review.opendev.org/c/openstack/sushy-tools/+/91211315:34
JayFI agree it's a bug not an rfe15:35
dtantsurIt's a lot of code, but I think the motivation is quite clear15:35
TheJuliaI think it could be, and sometimes bugs are a lot of code to fix. :(15:36
adam-metal3well the support for volumes and snapshots was missing completely so that is why I needed that amount of code15:36
TheJulia... a lot of that is test and docstrings :)15:36
adam-metal3and sadly volumes can be cloned from volumes taht complicates things15:36
dtantsurit was not an objection, just an observation15:37
adam-metal3and yes mostly unit tests15:37
cardoeSo somewhat related, do we have good docs on how to use the different test / emulation modes of sushy-tools?15:37
cardoeLike OpenStack VMs like adam-metal3 is doing?15:37
TheJuliacardoe: last time I looked, not really.15:37
TheJuliacardoe: Patches welcome is the saying :)15:37
cardoeOh for sure.15:38
JayFI've been trying to be better about asking for docs for sushy-tools changes15:38
cardoeI was just going to say maybe that's another place that the user story case could help.15:38
TheJuliaPlease keep in mind, it is a testing only tool, not meant for production in any context.15:38
cardoeAbsolutely.15:38
iurygregory++15:38
TheJuliaonward?15:38
cardoeI'll try to write something up.15:39
TheJuliacardoe: much appreciated!15:39
rpittauadam-metal3: one more topic for you, but /I think we discussed this already?15:39
adam-metal3yeh sure as I understand there is no issue with the sushy-tools bugfix (not RFE)15:39
adam-metal3Yeah I started to recieve reviews on the 3rd topic the encryption, thanks for that15:39
adam-metal3I just wanted to bring it up officially too15:40
adam-metal3[Adam] RFE IPA LUKS+TPM https://bugs.launchpad.net/ironic/+bug/2073762, proposal: https://review.opendev.org/c/openstack/ironic-specs/+/92499315:40
TheJuliaI started reviewing that today. I think some reformatting is going to help a lot15:40
TheJuliaI've echoed lots of dmitry's comments15:40
TheJuliaor, at least I am15:40
rpittauI geuss we can approve that RFE unless someone has objections\15:40
dtantsurThis is in a sense the opposite case: it has great background information but could use a bit more technical details15:40
adam-metal3Yes my take away was from dtantsur's comment taht a "sequence" type description is missing so I will extend the whole image and partition image sections with e2e workflow explanation15:42
TheJuliaI like the overall idea. I have some serious concerns15:43
JayFI'll note that re: technical details, we should be a bit flexible too, the LUKS stuff is a bear to get working IRL 15:43
JayFI am excited about the possibilities this feature enables though, and will look at that spec Soon(tm)15:43
dtantsurI'm definitely not suggesting to describe every line of the future code :)15:43
JayFhonestly that might be a good one to put on for the PTG if it's not fully specified by then15:43
TheJuliadtantsur: ++15:43
JayFor even if it is, to share context 15:43
rpittauit is indeed a potential topic for PTG15:44
TheJuliaI suspect this might have to be finalized at the ptg15:44
TheJuliaBecause it is a huge amount of work15:44
adam-metal3yeah agree, I will most probably pusth an e2e implementation for the whole disk image workflow to have some code present alongside the discussion anyways I am writing it already15:44
adam-metal3the partition image support is a bit more rocky path because of the initrd editing that I have proposed, I might need a different approach there15:46
rpittauadam-metal3: feel free to add the topic here https://etherpad.opendev.org/p/ironic-ptg-october-202415:46
JayFI will note that having the encryption method be pluggable would be super interesting to me. My downstream currently does disk encryption via a custom step assisted by an external device.15:46
TheJuliaTo be honest, I wouldn't be sad if partition image support for it was never implemented,15:46
JayFWe'd likely move to such a pluggable interface if it was flexible enough15:46
TheJuliaThe reality is that we have to do a weird dance to move artifacts over for proper UEFI boot to happen15:46
JayFI will note I *think* that is managed somewhat via the OOB, so making it a step/agent only thing wouldn't fly for that generic case15:47
TheJuliainside of a step, decisions can be made, but it has to know what is wanted by the user to make proper decisions15:47
TheJuliathat is actually a point of concern I have as well, but I need an overall flow to validate if I'm interpreting it the way that worries me15:48
TheJuliaOverall phases are a good thing, logically decomposing work is also a good thing15:48
rpittaulet's move on?15:49
TheJulia++15:49
JayF++15:49
adam-metal3++15:49
rpittaunext is me15:50
rpittauI have one "simple" question: do we want to support 2 ansible versions in bifrost?15:50
dtantsuras in: 2 major versions?15:50
rpittau2 major versions15:50
rpittauyeah15:50
iurygregorywo wo15:50
iurygregorywow wow15:50
iurygregory=O15:50
dtantsur*want* could be a strong word, but it's not impossible15:50
dtantsurwhat's the background?15:50
rpittauthe current situation is that ansible 9 is "going away"15:50
* TheJulia suggests "keeping it simple"15:50
rpittauand ansible 1 0requires pytho n3.1015:50
TheJuliawheeeeeeeeeeeee15:50
rpittauso we can't test that on centos9 :D15:50
dtantsurfun15:51
* TheJulia notes this is release note territory15:51
rpittauyeah15:51
rpittauso I have a patch to use both at the same time based on the distro15:51
JayFWe should involve kayobe in this decision, perhaps?15:51
rpittaubut yeah....15:51
iurygregoryohh god15:51
TheJuliain fact, if you could just propose a release note for usage of ansible on bifrost and ironic now to highlight operators will likely have issues15:51
JayFI rarely hear of people using bifrost directly in my day-to-day, but I know a *lot* of folks use kayobe to bootstrap15:51
rpittauJayF: probably, although we keep compatibility with ansible9 anyway15:51
JayFso maybe being nice and coordinating with them would be good15:51
dtantsurrpittau: I wonder if the situation with non-default Pythons in CentOS has improved15:52
TheJuliaJayF: that is a good point, at least on the what beyon raising awareness15:52
dtantsurPreviously, they lacked important packages15:52
* dtantsur podman run15:52
JayFSo I suggest 301-redirect this conversation to mailing list?15:52
TheJulia++15:52
rpittaudtantsur: it has improved, but I'm not sure about using a non default python in this case15:52
dtantsurwhy not?15:52
rpittauwe would it only in bifrost CI, nowhere else15:53
rpittauand it would mean abandon ansible915:53
dtantsurpython3-libselinux still has 1 version, nevermind15:53
rpittaualso yeah not sure about some packages15:54
dtantsurthe problematic are selinux, firewalld and dnf IIRC15:54
iurygregoryalways ...15:54
* TheJulia has to switch focus in 6 minutes15:54
rpittauI can probably complete the patch and see how it goes, and coordinate with kayobe if needed15:55
dtantsur++15:55
clarkbnot sure if this is a problem for bifrost too, but the new ansible version also drops a lot of ansible support for the remote nodes15:55
TheJuliaAssume you will need to since they are all ubutnu I think15:55
clarkbso you need python3.10 where yuo run ansible but then your inventory needs 3.8 or newer too iirc15:55
TheJuliaubuntu15:55
cardoeGonna be rude and just dump here cause I've gotta do a demo of Ironic internally in 6 minutes and I'll be sharing my screen. I'm wanting to fix up Ironic and anything it needs for Python 3.12. https://review.opendev.org/c/openstack/requirements/+/925306 is my blocker but I plan on sending you guys a bunch of changes once that lands for other pieces. Going to aim to drop all of setuptools rather than pull it in as a depend 15:56
cardoeso expect to see those changes coming.15:56
dtantsurclarkb: thanks! not a problem for us: we mostly run ansible locally15:56
rpittauclarkb: yeah there are some changes we need to test in advance15:56
JayFcardoe: no big deal, I think many of us have a hard stop at the hour :)15:56
TheJuliacardoe: cool cool, I think. Good luck!15:56
rpittaugood luck cardoe :)15:56
cardoeI've also got a lot of Dell gear that behaves badly. I'm not sure the best way to proceed to fix things. I've created https://bugs.launchpad.net/sushy/+bug/2075979 and just hoping for a suggestion. I'll write the code.15:57
rpittaualright I'll move forward with that and see15:57
cardoeLastly, to deal with these Dells... I need to touch BIOS settings without the IPA booting... so I made https://bugs.launchpad.net/ironic/+bug/2075980 but wanted to make sure that was okay before implementing something.15:57
rpittauwe just have bug deputy left15:57
rpittau#topic Bug Deputy Updates15:58
iurygregoryo/15:58
rpittauiurygregory: anything worth mentioning?15:58
* TheJulia notes this has been a super lively meeting15:58
iurygregoryrpittau, I've checked a few bugs, did the triage, closed some old ones15:58
iurygregorybut I was wondering about ironic-inspector bugs15:58
opendevreviewMerged openstack/bifrost master: Remove unused get_md5  https://review.opendev.org/c/openstack/bifrost/+/92566915:59
opendevreviewMerged openstack/bifrost master: Update min required pip version to 22.3.1  https://review.opendev.org/c/openstack/bifrost/+/92560215:59
rpittaucardoe: re: https://bugs.launchpad.net/sushy/+bug/2075979 that might be a problem on Dell side actually15:59
opendevreviewMerged openstack/bifrost master: pip: Use SETUPTOOLS_USE_STDLIB if python < 3.12  https://review.opendev.org/c/openstack/bifrost/+/92482815:59
iurygregoryI saw one that was recently reported (like in June)15:59
JayFMay be value in evaluating if those bugs would exist in the Ironic impl, and if so, porting the bug report over15:59
iurygregoryso I'm thinking if we would still accept changes there 15:59
rpittauiurygregory: we should treat inspector bugs as normal, the project is still active even if deprecated15:59
JayFotherwise probably should keep inspector fixes to medium+ bugfixes15:59
iurygregoryhttps://bugs.launchpad.net/ironic-inspector/+bug/207358815:59
iurygregory++15:59
iurygregoryok o/15:59
rpittauwe're out of time16:00
rpittauany volunteer for this week bug deputy?16:00
TheJuliaI'm slammed16:00
rpittauheh me too :/16:00
cidI could 16:00
JayFthanks cid16:00
rpittauthanks cid :)16:01
rpittauthanks all!16:01
rpittau#endmeeting16:01
opendevmeetMeeting ended Mon Aug  5 16:01:08 2024 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:01
opendevmeetMinutes:        https://meetings.opendev.org/meetings/ironic/2024/ironic.2024-08-05-15.00.html16:01
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/ironic/2024/ironic.2024-08-05-15.00.txt16:01
opendevmeetLog:            https://meetings.opendev.org/meetings/ironic/2024/ironic.2024-08-05-15.00.log.html16:01
rpittaugood night! o/16:01
cidiurygregory: I had a few questions.16:02
cidHow did you manage to trace landed changes that the bugs were still open.16:02
cidAny special approach or just check every bug?16:02
cidAnd a more general question: I usually focus only on triaging bugs filled within the within the week I'm deputy.16:05
cidIs that the right thing to do?16:05
JayFWe assign a deputy because when it was everyones' responsibility, it was hard for any single person to prioritize it.16:06
JayFThere's nothing wrong with doing it more; we just wanted someone who had independent repsonsibility.16:06
opendevreviewRiccardo Pittau proposed openstack/bifrost master: [WIP] Test 2 major ansible versions  https://review.opendev.org/c/openstack/bifrost/+/92556316:18
dtantsurA new low hanging fruit filed: https://bugs.launchpad.net/ironic/+bug/207611116:22
dtantsurcid: also related to the docs if you're on this topic ^^16:22
cidSure16:24
cidJayF, understood.16:25
iurygregoryhey cid o/16:41
iurygregorysorry, I was having lunch16:42
cidNo worries 16:42
iurygregorycid, let me try to give you an example on how I normally do16:43
iurygregoryFor https://bugs.launchpad.net/ironic-python-agent/+bug/2066308 the OpenStack bot provided the answer, so I just updated things, I've checked the repo looking for the bug id 2066308 16:46
iurygregorynot sure why the bot didn't mark as Fix Released etc =(16:46
iurygregoryFor https://bugs.launchpad.net/networking-generic-switch/+bug/1737017 I added a comment to mark as triaged since I think the problem was valid, but then I noticed the bug was old and maybe people would have fixed that, so I checked the repo for the bug id and I've found the commit that fixed the problem16:49
iurygregorysometimes people can forgot to mention the id, but if the description has enough info you may be able to look at the code and search for some key-words like Dell Force 10, or the error message etc16:51
* cid wites: if it's a bit old, I check if it already has a fix.16:51
iurygregoryI guess you already know about https://github.com/dtantsur/ironic-bug-dashboard right?16:52
cidiurygregory: is hudson-openstack in 2066308 a bot?16:52
iurygregorycid, correct!16:52
cidYes I know about the dashboard 16:52
iurygregorywhen I started to work with openstack in 2015, I thought it was a person :D16:53
cid:D, I always like to be sure 16:53
iurygregory++16:53
cidiurygregory: thanks a lot16:54
iurygregorycid, yw, happy to help!16:54
JayFhudson is what jenkins used to be called16:54
JayFjenkins was our runner before zuul16:54
JayFit's so many steps removed from someone new!16:54
iurygregoryJayF, really?!16:54
iurygregorywow16:54
JayFjenkins is a fork of hudson iirc16:55
iurygregorygot it!16:55
cidJayF: I suspect hudson is an openstack project?16:57
JayFpredates us by a good bit16:57
cidOh wow16:58
JayFzuul was created by openstack devs because we outgrew hudson17:00
JayFfungi or clarkb probably have a clearer image of the actual story17:00
JayFs/hudson/jenkins/17:00
cardoeWell Ironic didn't eat my dog so great success. :-D17:00
cardoerpittau: you mentioned by hardware might be a Dell problem. Should I try and add some workaround into sushy-oem-idrac? Or do I need to be yelling at Dell and just blacklist this iDRAC version?17:01
fungicid: iurygregory: JayF: i chronicled the history in https://zuul-ci.org/blog/#20200207a17:01
JayFI suggest to yell at dell regardless of how you workaround17:01
iurygregoryfungi, oh nice! 17:06
cidfungi tks17:06
* iurygregory add to bookmarks to read later17:07
TheJuliacardoe: we highly encourage yelling at dell, and working around. They might fix issues with minimal yelling, but they can be slow, and sometimes re-introduce the same issue later18:24
cardoewill do18:25
cido/20:45
JayF\o20:54

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!