rpittau | good morning ironic! o/ | 07:07 |
---|---|---|
adam-metal3 | good morning ironic! o/ | 07:25 |
opendevreview | Riccardo Pittau proposed openstack/bifrost master: Remove unused get_md5 https://review.opendev.org/c/openstack/bifrost/+/925669 | 07:53 |
opendevreview | Riccardo Pittau proposed openstack/bifrost master: Remove unused get_md5 https://review.opendev.org/c/openstack/bifrost/+/925669 | 07:54 |
opendevreview | Riccardo Pittau proposed openstack/bifrost master: Uplift default Ansible version to 9.x https://review.opendev.org/c/openstack/bifrost/+/925563 | 07:54 |
Continuity | Ah no worries TheJulia. Im around most of the time as you have seen :D | 08:03 |
opendevreview | Dmitry Tantsur proposed openstack/ironic master: DevStack: enable the new in-band inspection by default https://review.opendev.org/c/openstack/ironic/+/925688 | 11:29 |
opendevreview | cid proposed openstack/ironic master: [WIP] docs-audit-2024: Labeling references https://review.opendev.org/c/openstack/ironic/+/925691 | 12:24 |
opendevreview | cid proposed openstack/ironic master: [WIP] docs-audit-2024: Use a description for concept headings https://review.opendev.org/c/openstack/ironic/+/925692 | 12:24 |
opendevreview | cid proposed openstack/ironic master: [WIP] docs-audit-2024: Use gerunds for task headings https://review.opendev.org/c/openstack/ironic/+/925129 | 12:25 |
TheJulia | good morning | 13:21 |
opendevreview | Adam Rozman proposed openstack/ironic master: implement custom reboot support https://review.opendev.org/c/openstack/ironic/+/925703 | 13:24 |
adam-metal3 | Just 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 |
TheJulia | adam-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-metal3 | TheJulia: it is just a new property not a new step | 14:24 |
TheJulia | ack, cool cool | 14:24 |
TheJulia | your first two rfes, at least lgtm | 14:24 |
TheJulia | your 2nd might just be a bug depending on point of view | 14:24 |
TheJulia | I need more cofffeeeeeee for the third | 14:24 |
adam-metal3 | TheJulia: Thanks for the feedback! | 14:30 |
dtantsur | adam-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 |
dtantsur | this RFE could use a user story explained | 14:34 |
adam-metal3 | dtantsur: 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-metal3 | mayb do systemd re initialization or kernel swapping or something that is not part of the regural workflow and might even turns the IPA off | 14:39 |
adam-metal3 | I will add a few of these examples | 14:45 |
dtantsur | adam-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-metal3 | dtantsur: 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-metal3 | and ask for a custom reboot process | 14:55 |
dtantsur | This 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-metal3 | it can't because even if I use custom deploy step Ironic will restart the machine and I would like to avoid that, | 14:56 |
dtantsur | A configuration option maybe? | 14:56 |
JayF | This is honestly something that even if we did, we might wanna hide in e.g. custom-agent driver | 14:56 |
dtantsur | I'm thinking how to avoid an API flag that will break things for 99.9% of users | 14:57 |
dtantsur | (if they try to use it, of course) | 14:57 |
JayF | I 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 now | 14:57 |
JayF | and serves a single weirdo use case | 14:57 |
* TheJulia blinks | 14:57 | |
dtantsur | Oh, hmm, if it's only for custom-agent and is inside driver_info.. I can live with it, I guess | 14:57 |
adam-metal3 | So 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 manager | 14:58 |
TheJulia | dtantsur: that was the way I was reading it | 14:58 |
TheJulia | but would be good to be slightly more specific | 14:58 |
dtantsur | adam-metal3: I might have misread the RFE a bit. So it's not exposed in the API? | 14:58 |
TheJulia | I was thinking it would be something the overall context would be determined through the runtime of the custom agent | 14:59 |
JayF | reboot is not a step; that's the thing | 14:59 |
JayF | reboot is like, 14 steps | 14:59 |
TheJulia | Yeah | 14:59 |
TheJulia | for ironic, it is | 14:59 |
adam-metal3 | it is not part of the reboot | 14:59 |
JayF | and it seems to me we'd have to break it up, aka deploy steps, in order to allow the customization | 14:59 |
TheJulia | and removing it by any default begins to tear down the security barrier we lay down | 14:59 |
TheJulia | might be better as a high bandwidth discussion, fwiw | 14:59 |
TheJulia | (since we're all got different reads of it) | 14:59 |
TheJulia | we've | 14:59 |
* TheJulia makes coffee | 15:00 | |
rpittau | right in time! | 15:00 |
rpittau | #startmeeting ironic | 15:00 |
opendevmeet | Meeting 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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
opendevmeet | The meeting name has been set to 'ironic' | 15:00 |
masghar | o/ | 15:00 |
TheJulia | o/ | 15:00 |
adam-metal3 | o/ | 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_August_05.2C_2024 | 15:00 |
cid | o/ | 15:00 |
dtantsur | o/ | 15:00 |
rpittau | #topic Announcements/Reminders | 15:01 |
rpittau | Standing reminder to review patches tagged ironic-week-prio and to hashtag any patches ready for review with ironic-week-prio | 15:01 |
rpittau | #link https://tinyurl.com/ironic-weekly-prio-dash | 15:01 |
iurygregory | o/ | 15:02 |
rpittau | we have some patches in merge conflict in the list, worth having a look there | 15:02 |
rpittau | #info 2024.2 Dalmatian Release Schedule | 15:03 |
rpittau | #link https://releases.openstack.org/dalmatian/schedule.html | 15:03 |
opendevreview | Maryna Savchenko proposed openstack/ironic master: Fixes config drive base64 encoding in kickstart file https://review.opendev.org/c/openstack/ironic/+/925569 | 15:03 |
rpittau | we're at R-8 two months to go! | 15:03 |
TheJulia | k, I'll try to rebase those this week | 15:03 |
rpittau | thanks TheJulia :) | 15:03 |
opendevreview | Maryna Savchenko proposed openstack/ironic master: Fixes config drive base64 encoding in kickstart file https://review.opendev.org/c/openstack/ironic/+/925569 | 15:03 |
rpittau | Feature Freeze is in 3 weeks | 15:03 |
JayF | I really, really need reviews on ironic-guest-metadata | 15:04 |
JayF | because Nova will enforce FF | 15:04 |
iurygregory | ++ | 15:05 |
rpittau | JayF: I see it's failing CI, unrelated ? | 15:05 |
JayF | yes | 15:05 |
opendevreview | Maryna Savchenko proposed openstack/ironic master: Fixes config drive base64 encoding in kickstart file https://review.opendev.org/c/openstack/ironic/+/925569 | 15:05 |
JayF | just not rechecking like a madman on something that almost certainly will get revised | 15:05 |
rpittau | ok | 15:05 |
rpittau | any other priorities since we're close to FF ? | 15:06 |
cid | What's FF? | 15:06 |
rpittau | Feature Freeze | 15:06 |
cid | Oh, okay | 15:06 |
cid | I'm soliciting reviews on runbooks | 15:07 |
TheJulia | JayF: so you need it merged, what, this week? | 15:07 |
TheJulia | in ironic/. | 15:07 |
TheJulia | ? | 15:07 |
cid | Any feedback is appreciated | 15:07 |
JayF | TheJulia: I need feedback on the Ironic and Nova changes, and I will ask Nova for nova side reviews | 15:07 |
JayF | TheJulia: the feature basically straddles both projects so I see it as a situation where both should be +2 before either lands | 15:08 |
TheJulia | JayF: if you can post a link, don't know if that is a topic or hashtag | 15:08 |
masghar | I cant find it in the weekly priorities patches | 15:08 |
rpittau | #link https://review.opendev.org/c/openstack/ironic/+/924887 | 15:08 |
masghar | Thanks! | 15:08 |
JayF | TheJulia: https://review.opendev.org/q/topic:%22ironic-guest-metadata%22 | 15:08 |
iurygregory | cid, I will take other look this week, the patch is big, but trill wed I should provide some feedback | 15:08 |
cid | Tks | 15:09 |
rpittau | ok moving on | 15:09 |
rpittau | #info the next OpenInfra PTG which will take place October 21-25, 2024 virtually! don't forget to register | 15:10 |
rpittau | add your name and topics to the etherpad | 15:10 |
rpittau | #link https://etherpad.opendev.org/p/ironic-ptg-october-2024 | 15:10 |
TheJulia | JayF: thanks | 15:10 |
rpittau | we'll have to decide the schedule soon so please add your topics there | 15:10 |
rpittau | btw 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-elections | 15:12 |
JayF | Do you intend to run again? | 15:12 |
rpittau | JayF: not sure, I'm still evaluating some things at the moment | 15:13 |
TheJulia | please let us know soon if you decide not to | 15:14 |
JayF | Yeah, someone else has to carve that time out if you don't | 15:14 |
cardoe | So I've been nudged to run for TC so I intend on doing that. | 15:14 |
rpittau | TheJulia: as soon as I know I will let the community know | 15:15 |
cardoe | I 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 |
JayF | cardoe didn't even make me get out my cudgel | 15:16 |
rpittau | onward! | 15:17 |
rpittau | #topic Review Ironic CI status | 15:17 |
rpittau | seems like the CI was pretty stable last week | 15:18 |
rpittau | anything worth mentioning ? | 15:18 |
rpittau | alright! | 15:19 |
rpittau | #topic Discussions | 15:19 |
TheJulia | cardoe: added the ironic-week-prio label to that change | 15:19 |
rpittau | adam-metal3: you have 3 topics | 15:19 |
adam-metal3 | rpittau: yes | 15:19 |
adam-metal3 | should I go one by one or should I just answer questions? | 15:20 |
rpittau | adam-metal3: let's do that in order, I think a discussione already started before the meeting | 15:20 |
TheJulia | +1 to one by one | 15:21 |
adam-metal3 | sure | 15:21 |
adam-metal3 | So 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 implementation | 15:22 |
adam-metal3 | In 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 failure | 15:23 |
dtantsur | Re reboot: I've left a comment about using deploy steps overrides - please check | 15:23 |
adam-metal3 | the 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 |
JayF | I 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 |
dtantsur | Re sushy-tools: I don't care much about it as long as the implementation is not too crazy to review and maintain | 15:24 |
JayF | and you can answer "why does this exist" just by reading the repo/docs | 15:24 |
JayF | (re sushy-tools ^) | 15:24 |
cardoe | Personally 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 |
TheJulia | re: reboot, I think there is a miss-conveyance of context | 15:25 |
adam-metal3 | oo shit so the first was the reboot | 15:25 |
TheJulia | because the proposal reads as a step, but *not really* based upon the code. Just highlighting as it is a risk to create confusion | 15:25 |
adam-metal3 | sorry sorry for the reboot I have the explanation here: | 15:25 |
adam-metal3 | So 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-metal3 | step (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-metal3 | contained within the custom hardware manager. | 15:25 |
JayF | yeah but that's based in a flawed assumption: that the machine, if rebooted in-band, would be able to recover itself | 15:26 |
dtantsur | What I mean is: disabling reboot after deployment is possible now, via deploy steps | 15:26 |
JayF | how does Ironic know when to flip the network if I have that enabled? | 15:26 |
cardoe | So can you go into what the overall goal is? What's the big overall problem to solve? | 15:26 |
JayF | that'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-steps | 15:27 |
TheJulia | I suspect this might be a separate case to support, not the default usage case, fwiw | 15:27 |
cardoe | JayF: yeah that's a question I would have as well. How do it know when to move that. | 15:27 |
cardoe | explicit++ | 15:27 |
TheJulia | That is sort of critical for those with security boundries to maintain | 15:27 |
TheJulia | but maybe custom-agent is not that deployment interface? | 15:28 |
dtantsur | I guess what we all miss is a pretty detailed user story | 15:28 |
cardoe | ^ agreed | 15:28 |
JayF | yeah 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" mode | 15:28 |
TheJulia | dtantsur: ++++ | 15:28 |
dtantsur | JayF: this is how we use it in OpenShift, yes | 15:29 |
adam-metal3 | So I would need to provide a user-story, that is fine | 15:30 |
TheJulia | And I think that is fine, just need to be expressly understood and shared around the differences for interfaces because they all serve different problem spaces | 15:30 |
adam-metal3 | is tehre something else that is an issue ? | 15:30 |
dtantsur | It's hard to tell until we know the WHY | 15:30 |
TheJulia | adam-metal3: just a statement to set us all to the same context as to how the usage will occur | 15:30 |
TheJulia | We need to be able to answer Why | 15:30 |
JayF | adam-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 |
TheJulia | And we're all at different starting places with different contexts | 15:31 |
TheJulia | which is why the discussion has headed down the path it has | 15:32 |
TheJulia | We should likely move on to the next item | 15:32 |
adam-metal3 | so 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-metal3 | or just on the chat? | 15:32 |
rpittau | adam-metal3: just on the RFE | 15:33 |
JayF | and you can always use chats in IRC/meeting to refine if folks are around | 15:33 |
TheJulia | yeah, on the RFE. Something to help us get to the same place so we unerstand why | 15:33 |
TheJulia | JayF: ++ | 15:33 |
adam-metal3 | Okay then for the second the sushy tool improvement , do Is is there something I should do there in your opinion ? | 15:34 |
JayF | can you link it? | 15:34 |
TheJulia | That reads like a bug to me | 15:34 |
rpittau | I was thinking the same | 15:34 |
TheJulia | "I can't use this snapshot which is a registered VM" | 15:34 |
adam-metal3 | Adam] 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/+/912113 | 15:34 |
JayF | I agree it's a bug not an rfe | 15:35 |
dtantsur | It's a lot of code, but I think the motivation is quite clear | 15:35 |
TheJulia | I think it could be, and sometimes bugs are a lot of code to fix. :( | 15:36 |
adam-metal3 | well the support for volumes and snapshots was missing completely so that is why I needed that amount of code | 15:36 |
TheJulia | ... a lot of that is test and docstrings :) | 15:36 |
adam-metal3 | and sadly volumes can be cloned from volumes taht complicates things | 15:36 |
dtantsur | it was not an objection, just an observation | 15:37 |
adam-metal3 | and yes mostly unit tests | 15:37 |
cardoe | So somewhat related, do we have good docs on how to use the different test / emulation modes of sushy-tools? | 15:37 |
cardoe | Like OpenStack VMs like adam-metal3 is doing? | 15:37 |
TheJulia | cardoe: last time I looked, not really. | 15:37 |
TheJulia | cardoe: Patches welcome is the saying :) | 15:37 |
cardoe | Oh for sure. | 15:38 |
JayF | I've been trying to be better about asking for docs for sushy-tools changes | 15:38 |
cardoe | I was just going to say maybe that's another place that the user story case could help. | 15:38 |
TheJulia | Please keep in mind, it is a testing only tool, not meant for production in any context. | 15:38 |
cardoe | Absolutely. | 15:38 |
iurygregory | ++ | 15:38 |
TheJulia | onward? | 15:38 |
cardoe | I'll try to write something up. | 15:39 |
TheJulia | cardoe: much appreciated! | 15:39 |
rpittau | adam-metal3: one more topic for you, but /I think we discussed this already? | 15:39 |
adam-metal3 | yeh sure as I understand there is no issue with the sushy-tools bugfix (not RFE) | 15:39 |
adam-metal3 | Yeah I started to recieve reviews on the 3rd topic the encryption, thanks for that | 15:39 |
adam-metal3 | I just wanted to bring it up officially too | 15:40 |
adam-metal3 | [Adam] RFE IPA LUKS+TPM https://bugs.launchpad.net/ironic/+bug/2073762, proposal: https://review.opendev.org/c/openstack/ironic-specs/+/924993 | 15:40 |
TheJulia | I started reviewing that today. I think some reformatting is going to help a lot | 15:40 |
TheJulia | I've echoed lots of dmitry's comments | 15:40 |
TheJulia | or, at least I am | 15:40 |
rpittau | I geuss we can approve that RFE unless someone has objections\ | 15:40 |
dtantsur | This is in a sense the opposite case: it has great background information but could use a bit more technical details | 15:40 |
adam-metal3 | Yes 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 explanation | 15:42 |
TheJulia | I like the overall idea. I have some serious concerns | 15:43 |
JayF | I'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 |
JayF | I am excited about the possibilities this feature enables though, and will look at that spec Soon(tm) | 15:43 |
dtantsur | I'm definitely not suggesting to describe every line of the future code :) | 15:43 |
JayF | honestly that might be a good one to put on for the PTG if it's not fully specified by then | 15:43 |
TheJulia | dtantsur: ++ | 15:43 |
JayF | or even if it is, to share context | 15:43 |
rpittau | it is indeed a potential topic for PTG | 15:44 |
TheJulia | I suspect this might have to be finalized at the ptg | 15:44 |
TheJulia | Because it is a huge amount of work | 15:44 |
adam-metal3 | yeah 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 already | 15:44 |
adam-metal3 | the partition image support is a bit more rocky path because of the initrd editing that I have proposed, I might need a different approach there | 15:46 |
rpittau | adam-metal3: feel free to add the topic here https://etherpad.opendev.org/p/ironic-ptg-october-2024 | 15:46 |
JayF | I 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 |
TheJulia | To be honest, I wouldn't be sad if partition image support for it was never implemented, | 15:46 |
JayF | We'd likely move to such a pluggable interface if it was flexible enough | 15:46 |
TheJulia | The reality is that we have to do a weird dance to move artifacts over for proper UEFI boot to happen | 15:46 |
JayF | I 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 case | 15:47 |
TheJulia | inside of a step, decisions can be made, but it has to know what is wanted by the user to make proper decisions | 15:47 |
TheJulia | that 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 me | 15:48 |
TheJulia | Overall phases are a good thing, logically decomposing work is also a good thing | 15:48 |
rpittau | let's move on? | 15:49 |
TheJulia | ++ | 15:49 |
JayF | ++ | 15:49 |
adam-metal3 | ++ | 15:49 |
rpittau | next is me | 15:50 |
rpittau | I have one "simple" question: do we want to support 2 ansible versions in bifrost? | 15:50 |
dtantsur | as in: 2 major versions? | 15:50 |
rpittau | 2 major versions | 15:50 |
rpittau | yeah | 15:50 |
iurygregory | wo wo | 15:50 |
iurygregory | wow wow | 15:50 |
iurygregory | =O | 15:50 |
dtantsur | *want* could be a strong word, but it's not impossible | 15:50 |
dtantsur | what's the background? | 15:50 |
rpittau | the current situation is that ansible 9 is "going away" | 15:50 |
* TheJulia suggests "keeping it simple" | 15:50 | |
rpittau | and ansible 1 0requires pytho n3.10 | 15:50 |
TheJulia | wheeeeeeeeeeeee | 15:50 |
rpittau | so we can't test that on centos9 :D | 15:50 |
dtantsur | fun | 15:51 |
* TheJulia notes this is release note territory | 15:51 | |
rpittau | yeah | 15:51 |
rpittau | so I have a patch to use both at the same time based on the distro | 15:51 |
JayF | We should involve kayobe in this decision, perhaps? | 15:51 |
rpittau | but yeah.... | 15:51 |
iurygregory | ohh god | 15:51 |
TheJulia | in fact, if you could just propose a release note for usage of ansible on bifrost and ironic now to highlight operators will likely have issues | 15:51 |
JayF | I rarely hear of people using bifrost directly in my day-to-day, but I know a *lot* of folks use kayobe to bootstrap | 15:51 |
rpittau | JayF: probably, although we keep compatibility with ansible9 anyway | 15:51 |
JayF | so maybe being nice and coordinating with them would be good | 15:51 |
dtantsur | rpittau: I wonder if the situation with non-default Pythons in CentOS has improved | 15:52 |
TheJulia | JayF: that is a good point, at least on the what beyon raising awareness | 15:52 |
dtantsur | Previously, they lacked important packages | 15:52 |
* dtantsur podman run | 15:52 | |
JayF | So I suggest 301-redirect this conversation to mailing list? | 15:52 |
TheJulia | ++ | 15:52 |
rpittau | dtantsur: it has improved, but I'm not sure about using a non default python in this case | 15:52 |
dtantsur | why not? | 15:52 |
rpittau | we would it only in bifrost CI, nowhere else | 15:53 |
rpittau | and it would mean abandon ansible9 | 15:53 |
dtantsur | python3-libselinux still has 1 version, nevermind | 15:53 |
rpittau | also yeah not sure about some packages | 15:54 |
dtantsur | the problematic are selinux, firewalld and dnf IIRC | 15:54 |
iurygregory | always ... | 15:54 |
* TheJulia has to switch focus in 6 minutes | 15:54 | |
rpittau | I can probably complete the patch and see how it goes, and coordinate with kayobe if needed | 15:55 |
dtantsur | ++ | 15:55 |
clarkb | not sure if this is a problem for bifrost too, but the new ansible version also drops a lot of ansible support for the remote nodes | 15:55 |
TheJulia | Assume you will need to since they are all ubutnu I think | 15:55 |
clarkb | so you need python3.10 where yuo run ansible but then your inventory needs 3.8 or newer too iirc | 15:55 |
TheJulia | ubuntu | 15:55 |
cardoe | Gonna 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 |
cardoe | so expect to see those changes coming. | 15:56 |
dtantsur | clarkb: thanks! not a problem for us: we mostly run ansible locally | 15:56 |
rpittau | clarkb: yeah there are some changes we need to test in advance | 15:56 |
JayF | cardoe: no big deal, I think many of us have a hard stop at the hour :) | 15:56 |
TheJulia | cardoe: cool cool, I think. Good luck! | 15:56 |
rpittau | good luck cardoe :) | 15:56 |
cardoe | I'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 |
rpittau | alright I'll move forward with that and see | 15:57 |
cardoe | Lastly, 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 |
rpittau | we just have bug deputy left | 15:57 |
rpittau | #topic Bug Deputy Updates | 15:58 |
iurygregory | o/ | 15:58 |
rpittau | iurygregory: anything worth mentioning? | 15:58 |
* TheJulia notes this has been a super lively meeting | 15:58 | |
iurygregory | rpittau, I've checked a few bugs, did the triage, closed some old ones | 15:58 |
iurygregory | but I was wondering about ironic-inspector bugs | 15:58 |
opendevreview | Merged openstack/bifrost master: Remove unused get_md5 https://review.opendev.org/c/openstack/bifrost/+/925669 | 15:59 |
opendevreview | Merged openstack/bifrost master: Update min required pip version to 22.3.1 https://review.opendev.org/c/openstack/bifrost/+/925602 | 15:59 |
rpittau | cardoe: re: https://bugs.launchpad.net/sushy/+bug/2075979 that might be a problem on Dell side actually | 15:59 |
opendevreview | Merged openstack/bifrost master: pip: Use SETUPTOOLS_USE_STDLIB if python < 3.12 https://review.opendev.org/c/openstack/bifrost/+/924828 | 15:59 |
iurygregory | I saw one that was recently reported (like in June) | 15:59 |
JayF | May be value in evaluating if those bugs would exist in the Ironic impl, and if so, porting the bug report over | 15:59 |
iurygregory | so I'm thinking if we would still accept changes there | 15:59 |
rpittau | iurygregory: we should treat inspector bugs as normal, the project is still active even if deprecated | 15:59 |
JayF | otherwise probably should keep inspector fixes to medium+ bugfixes | 15:59 |
iurygregory | https://bugs.launchpad.net/ironic-inspector/+bug/2073588 | 15:59 |
iurygregory | ++ | 15:59 |
iurygregory | ok o/ | 15:59 |
rpittau | we're out of time | 16:00 |
rpittau | any volunteer for this week bug deputy? | 16:00 |
TheJulia | I'm slammed | 16:00 |
rpittau | heh me too :/ | 16:00 |
cid | I could | 16:00 |
JayF | thanks cid | 16:00 |
rpittau | thanks cid :) | 16:01 |
rpittau | thanks all! | 16:01 |
rpittau | #endmeeting | 16:01 |
opendevmeet | Meeting ended Mon Aug 5 16:01:08 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:01 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2024/ironic.2024-08-05-15.00.html | 16:01 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2024/ironic.2024-08-05-15.00.txt | 16:01 |
opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2024/ironic.2024-08-05-15.00.log.html | 16:01 |
rpittau | good night! o/ | 16:01 |
cid | iurygregory: I had a few questions. | 16:02 |
cid | How did you manage to trace landed changes that the bugs were still open. | 16:02 |
cid | Any special approach or just check every bug? | 16:02 |
cid | And a more general question: I usually focus only on triaging bugs filled within the within the week I'm deputy. | 16:05 |
cid | Is that the right thing to do? | 16:05 |
JayF | We assign a deputy because when it was everyones' responsibility, it was hard for any single person to prioritize it. | 16:06 |
JayF | There's nothing wrong with doing it more; we just wanted someone who had independent repsonsibility. | 16:06 |
opendevreview | Riccardo Pittau proposed openstack/bifrost master: [WIP] Test 2 major ansible versions https://review.opendev.org/c/openstack/bifrost/+/925563 | 16:18 |
dtantsur | A new low hanging fruit filed: https://bugs.launchpad.net/ironic/+bug/2076111 | 16:22 |
dtantsur | cid: also related to the docs if you're on this topic ^^ | 16:22 |
cid | Sure | 16:24 |
cid | JayF, understood. | 16:25 |
iurygregory | hey cid o/ | 16:41 |
iurygregory | sorry, I was having lunch | 16:42 |
cid | No worries | 16:42 |
iurygregory | cid, let me try to give you an example on how I normally do | 16:43 |
iurygregory | For 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 |
iurygregory | not sure why the bot didn't mark as Fix Released etc =( | 16:46 |
iurygregory | For 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 problem | 16:49 |
iurygregory | sometimes 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 etc | 16:51 |
* cid wites: if it's a bit old, I check if it already has a fix. | 16:51 | |
iurygregory | I guess you already know about https://github.com/dtantsur/ironic-bug-dashboard right? | 16:52 |
cid | iurygregory: is hudson-openstack in 2066308 a bot? | 16:52 |
iurygregory | cid, correct! | 16:52 |
cid | Yes I know about the dashboard | 16:52 |
iurygregory | when I started to work with openstack in 2015, I thought it was a person :D | 16:53 |
cid | :D, I always like to be sure | 16:53 |
iurygregory | ++ | 16:53 |
cid | iurygregory: thanks a lot | 16:54 |
iurygregory | cid, yw, happy to help! | 16:54 |
JayF | hudson is what jenkins used to be called | 16:54 |
JayF | jenkins was our runner before zuul | 16:54 |
JayF | it's so many steps removed from someone new! | 16:54 |
iurygregory | JayF, really?! | 16:54 |
iurygregory | wow | 16:54 |
JayF | jenkins is a fork of hudson iirc | 16:55 |
iurygregory | got it! | 16:55 |
cid | JayF: I suspect hudson is an openstack project? | 16:57 |
JayF | predates us by a good bit | 16:57 |
cid | Oh wow | 16:58 |
JayF | zuul was created by openstack devs because we outgrew hudson | 17:00 |
JayF | fungi or clarkb probably have a clearer image of the actual story | 17:00 |
JayF | s/hudson/jenkins/ | 17:00 |
cardoe | Well Ironic didn't eat my dog so great success. :-D | 17:00 |
cardoe | rpittau: 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 |
fungi | cid: iurygregory: JayF: i chronicled the history in https://zuul-ci.org/blog/#20200207a | 17:01 |
JayF | I suggest to yell at dell regardless of how you workaround | 17:01 |
iurygregory | fungi, oh nice! | 17:06 |
cid | fungi tks | 17:06 |
* iurygregory add to bookmarks to read later | 17:07 | |
TheJulia | cardoe: 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 later | 18:24 |
cardoe | will do | 18:25 |
cid | o/ | 20:45 |
JayF | \o | 20:54 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!