| cardoe | Well what would you recommend, JayF? | 00:51 |
|---|---|---|
| JayF | Well, you can take two different approaches: are all of your users from Nova? All of your slas reschedule tolerant? | 01:49 |
| JayF | Then maybe you'd rather just kill the deploy in progress and get your restart completed more quickly | 01:50 |
| JayF | It's just about how you model failure in your system versus how much you value speed | 01:50 |
| JayF | The obvious other approach is that every build is precious in which case the sigusr2 is one of the bigger changes we've had in that direction | 01:50 |
| opendevreview | Steve Baker proposed openstack/networking-generic-switch master: WIP Add security group support to ovs https://review.opendev.org/c/openstack/networking-generic-switch/+/956519 | 05:00 |
| abongale | good morning ironic o/ | 06:46 |
| rpittau | good morning ironic! o/ | 06:56 |
| janders | hey rpittau o/ | 07:02 |
| rpittau | hey janders :) | 07:03 |
| opendevreview | Merged openstack/ironic-ui master: Imported Translations from Zanata https://review.opendev.org/c/openstack/ironic-ui/+/956852 | 09:32 |
| iurygregory | good morning ironic | 11:19 |
| TheJulia | good morning | 13:05 |
| janders | hey TheJulia o/ | 13:06 |
| TheJulia | morning janders | 13:13 |
| FreemanBoss[m] | Good afternoon o/ | 13:15 |
| * TheJulia workflows some stuffs | 13:23 | |
| TheJulia | Regarding merging abort verb for a failed state, I guess we could if others agree. | 13:27 |
| TheJulia | but I think there is some disagreement around that, but it is a cleanish escape hatch in a way that sort of does the same thing as unservice, and maybe because it is so user oriented at that point and about returning to the state, maybe it makes sense to add the same basic behavior for rescue too... | 13:28 |
| janders | yeah there's a few different options available | 13:30 |
| janders | do you think we could consider working towards merging abort-based approach in this cycle and iterate over it further in subsequent cycles? | 13:31 |
| janders | from my perspective, the big advantage of the abort-based approach is it's quite simple and doesn't need API changes | 13:32 |
| janders | having this would allow me and my team to continue working on downstream features that depend on having a reasonable way to escape service failed | 13:33 |
| janders | I'd be curious what you think, I added an item to meeting notes so we can also hear from others | 13:34 |
| cardoe | Good morning Ironic. | 13:36 |
| janders | hey cardoe | 13:36 |
| cardoe | JayF: So I'm tinkering with the default behavior for conductor in OpenStack Helm. Just wondering if I should set that to SIGUSR2 or not. | 13:37 |
| TheJulia | janders: I'm not opposed to it, but some folks seem opposed more so. I think there is validity in both approaches at the end of the day. | 13:38 |
| TheJulia | janders: *that being said*, my immediate focus is getting the eventlet stuffs landed. | 13:39 |
| janders | TheJulia totally understandable. I think once we have more clarity on the direction we'll go (API change or no API change), timing may be of less concern. I'm also happy to take on more/most effort on this and may be able to get some more folks involved, if they are willing. | 13:41 |
| janders | I will hang around and attend the meeting so we can discuss a bit more with the group | 13:42 |
| cardoe | TheJulia: so kinda random... if you use https://opendev.org/openstack/ironic/src/commit/e415f2a4410f2aa0fedb8b6d385722d756bfef4b/ironic/tests/unit/objects/utils.py#L75 in a test in the setUp(). Should task_manager.acquire(shared=True) give you a task where task.node is set to that node? | 13:45 |
| cardoe | I see in some places its set to None. And then I looked at some other tests we've got and one has a comment above the mock of acquire saying this is done so the node is set. | 13:46 |
| cardoe | I noticed a lot of code uses task.node.uuid but task.node can be None but we always store the node UUID as task.node_id so I'm wondering if the code should be changed to using task.node_id explicitly and that makes the None issue go away. | 13:47 |
| cardoe | Or if there's some unknown to me issue preventing acquire() from working in the tests. | 13:48 |
| TheJulia | janders: totally fair and I think that is the right decision, discuss and try and move in an unblocking direction ultimately | 13:49 |
| iurygregory | ++ | 13:50 |
| TheJulia | cardoe: so... I would think each test should sort of define what it needs and if a class level creation of a node works, then cool. I would sort of avoid creating the task and attaching it to the class self for the test's runtime specifically because if you need to change anything in the initial state, then you really ought, to at least follow the model, re-create the task.... or minimally refresh the node object on the | 13:51 |
| TheJulia | task. | 13:51 |
| TheJulia | cardoe: when you say places you see it set to None, do you mean kwargs called into the creation? | 13:51 |
| TheJulia | Another reviewers eyes on https://review.opendev.org/c/openstack/ironic/+/956512 and https://review.opendev.org/c/openstack/ironic/+/956504 would be appreciated, they should set us in a very happy state for Metal3 in the end. | 14:42 |
| JayF | cardoe: just know that if you activate that behavior, it's going to slow down restarts. IMO it's worth it... But it's enough of a change in behavior I might make it optional | 14:42 |
| cardoe | https://opendev.org/openstack/ironic/src/commit/e415f2a4410f2aa0fedb8b6d385722d756bfef4b/ironic/tests/unit/drivers/modules/inspector/test_interface.py#L33-L37 so that's where I'm seeing the tests overriding the behavior of acquire() since task.node is set to None | 14:44 |
| cardoe | acquire() is suppose to look up the Node object and set it to task.node when it finds it. | 14:45 |
| cardoe | But that doesn't seem to always work for the create_test_node() function created nodes. | 14:45 |
| TheJulia | ugh | 14:51 |
| TheJulia | I'm not really a fan of faking out the task :\ | 14:52 |
| TheJulia | #startmeeting ironic | 15:01 |
| opendevmeet | Meeting started Mon Aug 18 15:01:46 2025 UTC and is due to finish in 60 minutes. The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| opendevmeet | The meeting name has been set to 'ironic' | 15:01 |
| TheJulia | o/ | 15:01 |
| * TheJulia brews coffeeeeeeee | 15:01 | |
| JayF | #startmeeting ir.. jinx :D | 15:01 |
| JayF | o/ | 15:01 |
| janders | o/ | 15:02 |
| iurygregory | o/ | 15:02 |
| TheJulia | #chair JayF | 15:02 |
| opendevmeet | Current chairs: JayF TheJulia | 15:02 |
| TheJulia | there ;) | 15:02 |
| JayF | #info 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:02 |
| cid | o/ | 15:02 |
| rpittau | o/ | 15:02 |
| darkhackernc | o/ | 15:02 |
| JayF | #info https://releases.openstack.org/flamingo/schedule.html it's R-6. Time to land the things you want in this release! | 15:02 |
| TheJulia | ++++++ | 15:02 |
| JayF | #topic Working group: Standalone Networking | 15:03 |
| JayF | any updates from standalone networking NG? | 15:03 |
| TheJulia | alegacy_: o/ | 15:03 |
| TheJulia | I think alegacy_ indicated last week he was hitting some challenges with the retooling of jsonrpc stuffs | 15:04 |
| TheJulia | as it relates to the local conductor flow, but that is all I'm aware of | 15:04 |
| JayF | Is there a etherpad or something with the historical info so I can fill in gaps on what we're doing? | 15:04 |
| TheJulia | https://etherpad.opendev.org/p/ironic-standalone-networking | 15:05 |
| JayF | #link https://etherpad.opendev.org/p/ironic-standalone-networking | 15:05 |
| JayF | #topic Working group: Eventlet removal | 15:06 |
| JayF | have we an eventlet still? | 15:06 |
| TheJulia | Things should begin to merge in a few minutes | 15:06 |
| JayF | for ironic-proper | 15:06 |
| JayF | ipa is already eventletless | 15:06 |
| JayF | do we know if the neutron pieces of ngs/nbm are eventlet-free yet? | 15:06 |
| JayF | curious if we're actually getting eventlet-zero across the capital-P project | 15:06 |
| TheJulia | I need a few reviews later in the chain, but we're on the path to be eventlet free sometime in the next 24 hours | 15:06 |
| opendevreview | Merged openstack/ironic master: ci: temporary metal3 integration job disable https://review.opendev.org/c/openstack/ironic/+/956952 | 15:06 |
| TheJulia | ngs and nbm area already eventlet free afaik | 15:07 |
| JayF | they are in code we own for sure | 15:07 |
| TheJulia | they are much more dependent upon their launchers, neutron depending on the code path | 15:07 |
| JayF | yeah that's more what I was curious, if their launchers were eventlet-free | 15:07 |
| JayF | very possible b/c neutron has been making good progress | 15:07 |
| JayF | I might dig at that today | 15:07 |
| opendevreview | Merged openstack/ironic master: Replace GreenThreadPoolExecutor in conductor https://review.opendev.org/c/openstack/ironic/+/952939 | 15:08 |
| JayF | Good work to everyone on the eventlet removal, special thanks to cid TheJulia dtantsur hberaud and others who has been directly working on that stuff :D | 15:08 |
| opendevreview | Merged openstack/ironic master: Set the backend to threading https://review.opendev.org/c/openstack/ironic/+/953683 | 15:08 |
| JayF | lol thanks for the informational input, opendevreview :D | 15:08 |
| TheJulia | speaking of! | 15:08 |
| JayF | #topic Discussion topics: Clean exit from service fail | 15:09 |
| JayF | janders this had your name attached | 15:09 |
| janders | that's right | 15:09 |
| janders | we spent a fair bit of time talking about it last week | 15:09 |
| janders | we have two patches up, taking different approaches - fixing existing abort verb for servicing - and a new verb, unservice | 15:09 |
| JayF | I think the biggest issue I had with the unservice patch was us being certain no agent was booted if we're forgoing a reboot | 15:10 |
| janders | I raised my hand to talk about this because I am leading downstream work which depends on having a clean exit from service failed | 15:10 |
| JayF | I don't have any issues with us trying to land the things we need as long as we are sure we're not adding in a "leave agent running" bug\ | 15:10 |
| TheJulia | JayF: yeah, and I think that will require adding a bit more logic around "did we ever launch", which is fine. | 15:10 |
| TheJulia | I think the concern is ability to consume something before the cycle is out | 15:11 |
| JayF | the more ham-fisted "reboot everytime" option is likely a safe patch for this release | 15:11 |
| janders | my concern is whether we're able to land the "unservice" version in this cycle? | 15:11 |
| JayF | and we could add the "feature" to avoid the reboot as a follow-on next cycle | 15:11 |
| TheJulia | that path leaves abort, really as a middle ground | 15:11 |
| janders | it does feel like the abort pathway is more likely to make it | 15:11 |
| TheJulia | and thinking about it, I've reached this conclusion that it might not be awful to be able to abort a rescue in a stable state | 15:11 |
| rpittau | the abort path sounds like a good compromise at the moment | 15:11 |
| TheJulia | dunno, just thinking a middle ground of "we get what they are asking" makes sense over perfection which we can still strive towards as time progresses | 15:12 |
| JayF | I don't have a strong opinion what verb as long as we steer clear of the security-scary no-reboot bit (or take the time to do it very well) | 15:12 |
| rpittau | yeah, we can always keep working on the unservice verb during the next cycle | 15:12 |
| TheJulia | JayF: yeah, we need to do the same with abort, add "if we ever tried to boot the agent" logic | 15:12 |
| TheJulia | which is fine, its a centralized code path, we just need to wire it up | 15:12 |
| janders | to me it feels like if we remove the concern about the verb and related API change, we will be able to better focus on pinning down the security concern | 15:13 |
| janders | would you agree? | 15:13 |
| JayF | Consensus is: land a patch with a conservative approach; treat reboot-optimization as a secondary feature? | 15:13 |
| JayF | janders: I see them as separate. I don't think it'd be an api break for us to hook up unservice in a "it always reboots" kinda way, then in 2026.1 remove that reboot as optimization | 15:14 |
| janders | I tend to agree | 15:14 |
| TheJulia | I'm thinking the reboot handing is really trivial | 15:14 |
| JayF | the tough case is "we booted into an agent that couldn't lookup for some reason" | 15:14 |
| TheJulia | the issue is more which direction do we focus on in that adding an unservice verb is a heavier lift because we're needing to touch api+rpc as well | 15:14 |
| TheJulia | and we've got a lot we're trhing to land right now | 15:14 |
| TheJulia | i.e. the bigger the thing, the harder it will be over the next couple of weeks | 15:14 |
| janders | to me this is a vote towards abort | 15:15 |
| rpittau | I wold just go for the abort at this point | 15:15 |
| iurygregory | I would go with the abort approach at this point also | 15:15 |
| janders | if there are no strong objections, maybe let's go this way? | 15:15 |
| JayF | sure. For bonus points maybe hook unrescue up similarly for consistency :) | 15:15 |
| TheJulia | JayF: I have a solution for that specifically, its not a big deal in my mind, but I do get the concern and both patches need to handle it | 15:15 |
| TheJulia | I'm thinking we still do unrescue, tbh | 15:15 |
| iurygregory | I like the unservice, but due to the time we have for things landing eventlet removal etc it can be a pain | 15:15 |
| TheJulia | but... be ready for that not to land until next cycle | 15:15 |
| TheJulia | if it lands this cycle, cool | 15:16 |
| TheJulia | but a LOT is going on | 15:16 |
| iurygregory | ++ | 15:16 |
| JayF | yup, land the simple to get the time pressure off | 15:16 |
| janders | ++ | 15:16 |
| TheJulia | cool cool | 15:16 |
| TheJulia | okay, then I'll take the action item to update the abort patch later today | 15:16 |
| janders | that will be huge help for operators - and will allow me to wire in our downstream feature into it | 15:16 |
| janders | which would be great | 15:16 |
| JayF | #agreed Start with an abort-only patch for "unservice" so we can close the bug, do "unservice" verb later. | 15:16 |
| TheJulia | and foretell the possibility of an unservice verb in the future | 15:16 |
| JayF | Can we move on? | 15:17 |
| TheJulia | cool cool | 15:17 |
| TheJulia | ++ | 15:17 |
| janders | this is my top priority at the moment, so let me know how I can best help TheJulia | 15:17 |
| janders | yes | 15:17 |
| janders | thank you! | 15:17 |
| TheJulia | janders: I should have a patch up for you by your morning | 15:17 |
| JayF | #topic Discussion: Type annotations and checking | 15:17 |
| TheJulia | unless something else explodes | 15:17 |
| JayF | cid: you had brought this up | 15:17 |
| cid | Yeah. Trying to get the feel of the community about adding annotations and type checking in Ironic. | 15:17 |
| JayF | I am generally in favor at the face of it, I think this is a thing where the devil will be in the details/implementation | 15:17 |
| JayF | if you have strong opinions against or to what implementation it'd be good to mention ... | 15:18 |
| JayF | I do think there's some prior art in this area, maybe in SDKs and nova? I think nova did separate .pyi files | 15:19 |
| cid | Yeah. It's one of those things, if we think that's something we're open to. The implemention approach could be shaped during reviews. | 15:21 |
| JayF | I look forward to the quick | 15:21 |
| JayF | ***quick +2s on cid's changes to add typing :P | 15:21 |
| cid | ++ :D | 15:21 |
| JayF | cid: I'd say go for it; might be nice to pick something smaller like IPA for a test | 15:21 |
| TheJulia | ++ | 15:21 |
| JayF | cid: and that way we stay outta the hair of eventlet removal/apis/etc | 15:21 |
| TheJulia | get reviewers familiar and such | 15:21 |
| rpittau | yep, let's start from something small :) | 15:21 |
| TheJulia | and yeah, I suspect we won't be able to get it done "this cycle" | 15:21 |
| kubajj | o/ | 15:22 |
| JayF | cid: I strongly suggest you look at other openstack projects and follow their lead or have a good reason to be different :D | 15:22 |
| JayF | #agreed cid will pilot some type-checking changes in a smaller repo, like IPA | 15:22 |
| cid | Totally not this cycle. :! | 15:22 |
| JayF | eventually :D | 15:23 |
| JayF | back burner | 15:23 |
| JayF | etc | 15:23 |
| JayF | #topic Bug Deputy | 15:23 |
| JayF | cid was bug deputy, notes 3 new bugs none of which are rfes | 15:23 |
| JayF | anything interesting in those bugs? | 15:23 |
| JayF | who wants to be the next deputy? | 15:23 |
| cid | That was pretty much it | 15:23 |
| iurygregory | it will be me this week | 15:23 |
| cid | \o/ | 15:23 |
| JayF | #info iurygregory to be bug deputy next week | 15:24 |
| JayF | No RFEs for review, skipping that meeting portion. | 15:24 |
| JayF | #topic Open Discussion | 15:24 |
| iurygregory | wouldn't be "this week"? :D | 15:24 |
| iurygregory | lol | 15:24 |
| JayF | anything not on the agenda for discussion? | 15:24 |
| JayF | iurygregory: I signed you up for two weeks /s | 15:24 |
| alegacy_ | Hi... sorry I arrived late and didn't give my update earlier for standalone networking | 15:24 |
| iurygregory | ack :D | 15:24 |
| JayF | if you have something to add alegacy_ now is a great time | 15:24 |
| alegacy_ | I've resolved the RPC issues. Continuing to test various scenarios. | 15:24 |
| alegacy_ | Specifically, I've been prototyping some integration into OpenShift to make sure it would handle the scenarios there | 15:25 |
| alegacy_ | so far so good. | 15:25 |
| alegacy_ | I'll be on PTO for the next two weeks, but I'm hoping by this Friday I'll have things in a good place to start to open change requests when i'm back. | 15:25 |
| alegacy_ | i've identified some issues/things that need to be discussed so i'll update the etherpad | 15:26 |
| TheJulia | cool, as an FYI then, we're likely going to end up cutting the release around R-3 for this cycle | 15:26 |
| alegacy_ | ok, noted | 15:26 |
| * TheJulia is just guessing R-3 based upon the time left and the historical "oh noes, we need to fix x" last minute details | 15:27 | |
| JayF | Nice, thanks for the update alegacy_ | 15:27 |
| JayF | Anyone else have a topic for open discussion? | 15:27 |
| TheJulia | did you start a ptg etherpad? | 15:27 |
| JayF | I'm pretty sure that fell off a long list of items to do in my head /o\ | 15:28 |
| TheJulia | Speaking of etherpads, last week you wanted to begin discussing eventlet removal related testing | 15:28 |
| * JayF doin it now | 15:28 | |
| kubajj | I wanted to quickly ask while most people are here. For the safeguards, can we force having a volume name for all logical disks in the target raid config? (i.e. we would complain if it is not included if skip_block_devices mentions any volume name) | 15:28 |
| TheJulia | https://etherpad.opendev.org/p/ironic-eventlet-removal#56 has many questionmarks :) | 15:28 |
| TheJulia | kubajj: force it as a requirement now when it was not previously a requirement? | 15:29 |
| kubajj | TheJulia: yes, exactly (but only if the user mentions volume name in the skip list property - i.e. we would make it fail in validation) | 15:30 |
| TheJulia | This reminds me of the other person who has... VROCs. We likely need to patch the initial checking logic to go "no, don't need to do anything" with these devices/volumes | 15:30 |
| JayF | can we just add some concept of "skip_unnamed_volumes" as an additional filter | 15:30 |
| JayF | instead of making it magic? | 15:30 |
| TheJulia | kubajj: I guess the issue is going to be framing because the cat is sort of "out of the bag" | 15:30 |
| TheJulia | I guess I'm not opposed, but the concern which comes to mind is around upgrades or folks with prior schema definitions which makes me think it should be opt in or sort of like JayF has noted | 15:31 |
| kubajj | now we just add a generic volume name to lists (md127, or whatever its index is) | 15:31 |
| JayF | https://etherpad.opendev.org/p/ironic-ptg-2026.1 and is added to the whiteboard. I can't spell the name of our next release though so it's "G". | 15:31 |
| JayF | whoever decided that complex-to-spell name was a good release name owes me a dictionary or seventeen :D lol | 15:32 |
| kubajj | We would like to enforce all RAIDs to have a volume name (if there is a skip list with volume name on it) because of how we are planning to prevent cleaning them | 15:32 |
| kubajj | JayF: I am pretty sure that the Spanish community in an unnamed research institute manipulated the vote | 15:33 |
| JayF | kubajj and I thought the dalmatian-is-spelled-with-an-a was tough to learn :D | 15:34 |
| TheJulia | kubajj: so framing it as "this is a good practice to take on", then maybe with a knob and release note could be acceptable | 15:34 |
| janders | a good Gazpacho ain't bad | 15:34 |
| TheJulia | oh my | 15:34 |
| TheJulia | kubajj: is this so root device hints can be directly mapped by the user of software raid? | 15:35 |
| kubajj | TheJulia: this is for the scenario when there are two logical disks on a certain set of holder disks (let's say root with 100 GB and data with the rest). the volume data will be on skip list, but we want to wipe root. As a workaround, we want to keep the root array, but wipe its data, but then when we create configuration, we want to make sure that it is the correct logical disk to existing raid device pair - an alternative | 15:38 |
| kubajj | to enforcing volume names would be to check raid level and size, but checking size is difficult as some sizes are 'MAX' and even if they are not, from testing 100 GB is not actually 100 GB | 15:38 |
| TheJulia | okay | 15:38 |
| JayF | are you trying to avoid a case where a label drops off a data disk and you lose data? | 15:38 |
| kubajj | JayF: the scenario that we want is to have a hypervisor which has two logical disks on two SSDs (root is 100 and the rest is data). We can reinstall root, but keep data | 15:39 |
| kubajj | I am not 100% sure when we would want to do that, but we want to have the option :D | 15:40 |
| * TheJulia waits for the rebuild verb to re-appear | 15:40 | |
| kubajj | I guess it could be called rebuild, yes | 15:41 |
| kubajj | I just usually only evacuate the whole node in case something is wrong, not rebuild :D | 15:41 |
| JayF | This is what rebuild --preserve-ephemeral is for | 15:42 |
| TheJulia | yeah, but that whole preserve-ephemeral logic is different | 15:42 |
| JayF | I don't love the "magically save disks from cleaning" pattern in general so I'm probably not the best person to pitch this with tbh. | 15:42 |
| TheJulia | different purpose | 15:42 |
| JayF | I'm less scared of data loss; more scared of data leakage | 15:43 |
| TheJulia | yeah, I think what they are doing makes sense for their use case since they are taking a target pool of nodes and very specifically managing them because they have a ton of data on those other disks that re-copying would be a nightmare since its not really a general BMaaS pool machine | 15:43 |
| kubajj | JayF: we already have the removal of the flag in our decommissioning process, just need to actually make the "rebuild" not delete the data | 15:43 |
| TheJulia | "hi, my pool of 48 disks is all radio telescope data that we don't want to try and push over a wire every time" | 15:44 |
| JayF | TheJulia: your hadoop cluster can't sync over the data fast enough? is that what you said /s | 15:44 |
| kubajj | TheJulia: exactly, I think our storage team would like to have them on their quads with 4 JBODs each, just to prevent accidents | 15:44 |
| JayF | (same problems ten years later) :D | 15:44 |
| TheJulia | yeah, I think this exact same challenge has come up in past discussions regarding the SKA cluster | 15:45 |
| kubajj | anyway, I will take this as "yes, you can try to propose such a change" and finish the implementation | 15:45 |
| JayF | To be clear; not saying I'd -1 or -2 this, just maybe more reflecting why I don't review those IPA changes, I can't really bring myself to like that approach but don't wanna block it either | 15:45 |
| TheJulia | JayF: Yeah, I'm sort of in the same boat but also more inclined to review such changes because I do totally get where they are coming from. | 15:46 |
| JayF | better to have software that works for people than a perfect model of cleaning | 15:48 |
| TheJulia | unfortunately, yeah | 15:48 |
| TheJulia | and on a plus side, the folks that do this sort of thing do know what they are doing in that the managing very specific nodes for those purposes | 15:49 |
| JayF | TBH with stuff like this, I'm way more scared of the features' existance being an attractive nuisance to someone who only half-understands it | 15:49 |
| JayF | we have a handful of those in ironic already, but I can't pretend like it's easy enough to use someone is likely to not be filtered by that point | 15:49 |
| TheJulia | this is why I like very big warnings | 15:49 |
| * cardoe shakes off the crushing weight of Teams calls. | 15:50 | |
| * JayF sees the beginnings of a "Ironic Ghost Stories" blogpost/talk with a list of all the scary things you could misuse ironic for ;) | 15:50 | |
| * TheJulia hands cardoe a cup of coffee to remedy this weight of Teams calls. | 15:50 | |
| JayF | I think we're to the end of kubajj's questions though | 15:50 |
| JayF | 10 minutes left, anything else for open discussion? | 15:50 |
| TheJulia | JayF: concur :) | 15:51 |
| JayF | Last call for topics for the meeting? | 15:52 |
| TheJulia | I've got nothing | 15:52 |
| cardoe | Last call? Was I on Teams calls that long. :( | 15:52 |
| cardoe | I've got nothing. | 15:52 |
| JayF | Thanks o/ | 15:53 |
| JayF | #endmeeting | 15:53 |
| opendevmeet | Meeting ended Mon Aug 18 15:53:07 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:53 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2025/ironic.2025-08-18-15.01.html | 15:53 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2025/ironic.2025-08-18-15.01.txt | 15:53 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2025/ironic.2025-08-18-15.01.log.html | 15:53 |
| janders | thank you all o/ | 15:53 |
| cardoe | TheJulia: that task question... https://ea5c37c06ce6e77863cd-be2db655edae902b1f8d9628c9b7e990.ssl.cf1.rackcdn.com/openstack/4fa50259fc974367adb228076b98a54a/testr_results.html that's what I'm looking at... specifically if you open the "test_inspect_hardware_ignore_missing_boot_mode" test and see the NoneType error. | 15:53 |
| JayF | I have a whole thing in https://etherpad.opendev.org/p/ironic-ptg-2026.1 about redfish annoyances stuff | 16:00 |
| cardoe | JayF: https://review.opendev.org/c/openstack/sushy/+/955701 very roughly I made a quirks module suggestion | 16:08 |
| cardoe | Folks have previously suggested adding something into the driver_info to have it hit vendor extensions in the past and that's gotten hung up. | 16:08 |
| cardoe | Like... https://review.opendev.org/c/openstack/ironic/+/634373 | 16:09 |
| JayF | that's the issue ... it's not a quirk | 16:14 |
| JayF | sushy's front door is "get_system" | 16:14 |
| JayF | you can't have 3 systems if the front door is get_system unless all that logic lives in Ironic | 16:14 |
| JayF | I don't wanna play whack-a-mole if we can help it, although I'm not sure I'm clever enough to find the generic solution (yet?) | 16:15 |
| TheJulia | cardoe: yeah, I feel like the pattern the test is written is not one I would do myself, the mocking the task and all for... just feels wrong to me. | 16:26 |
| TheJulia | One more review needed: https://review.opendev.org/c/openstack/ironic/+/956512 | 16:48 |
| JayF | 👀 | 16:48 |
| JayF | cardoe: you OK with me landing that? You only had a +1 and a comment | 16:49 |
| JayF | if so I will approve; I think perf testing will reveal where the hotspots are | 16:49 |
| JayF | and landing this will help us find those | 16:49 |
| cardoe | Yeah. | 16:50 |
| JayF | TheJulia: you want me to land this as-is and you follow-up after the stack goes? https://review.opendev.org/c/openstack/ironic/+/956504/13..16#message-d1374bd8fa2721ab7b19fb6040a887718aca8f66 | 16:51 |
| JayF | I don't wanna ask you to restack for a couple of print() in tests | 16:51 |
| TheJulia | doh, I can change change it | 16:52 |
| TheJulia | I'll just modify that one and rebase the following patches since they are all straight forward | 16:52 |
| JayF | ack; I'll drop on my +2 on that after it's done, if cardoe or cid will refresh there's I'll approve | 16:53 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Optional indirection API use https://review.opendev.org/c/openstack/ironic/+/956504 | 16:53 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Revert "ci: temporary metal3 integration job disable" https://review.opendev.org/c/openstack/ironic/+/956953 | 16:53 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Clean-up misc eventlet references https://review.opendev.org/c/openstack/ironic/+/955632 | 16:54 |
| TheJulia | clean enough | 16:54 |
| TheJulia | done | 16:54 |
| cardoe | I only +1'd it due to the comment about memory and suggesting a generic function. | 16:54 |
| JayF | that's what I figured, optimization post-testing is wise | 16:55 |
| cardoe | There's a couple of places that pattern is already done in ironic | 16:55 |
| JayF | I suspect memory will be less of an issue than contention | 16:55 |
| JayF | ram is cheap these days anyway | 16:55 |
| JayF | cardoe: you mind +2 on 956504 since she restacked? Then I can land the stack again | 16:55 |
| cardoe | done | 16:56 |
| * TheJulia loads up zuul | 16:57 | |
| TheJulia | eww, zuul restarted one of the patches entirely 34 minutes ago :( | 16:58 |
| TheJulia | oh well | 16:58 |
| JayF | stack is approved all the way to the docs | 16:58 |
| JayF | so if it can land it will | 16:59 |
| JayF | go CI go | 16:59 |
| TheJulia | you can do it CI! you can do it! | 17:00 |
| TheJulia | looks like jobs are now failing, but appear to be failing due to mirror states | 17:50 |
| TheJulia | I guess we'll have to give things a little time to resync | 17:50 |
| opendevreview | Verification of a change to openstack/ironic master failed: Fix service failed state transitions for wait/hold https://review.opendev.org/c/openstack/ironic/+/957290 | 17:52 |
| opendevreview | Clif Houck proposed openstack/ironic master: Add a new 'category' field to the Port object https://review.opendev.org/c/openstack/ironic/+/955447 | 18:37 |
| opendevreview | Clif Houck proposed openstack/ironic master: Add a new 'physical_network' field to the Portgroup object https://review.opendev.org/c/openstack/ironic/+/955625 | 18:41 |
| opendevreview | Clif Houck proposed openstack/ironic master: Add a new 'category' field to the Portgroup object https://review.opendev.org/c/openstack/ironic/+/955713 | 18:52 |
| opendevreview | Merged openstack/ironic-ui master: Capitalize RAID https://review.opendev.org/c/openstack/ironic-ui/+/956647 | 19:43 |
| opendevreview | Verification of a change to openstack/ironic master failed: Launch vnc proxy with no_fork https://review.opendev.org/c/openstack/ironic/+/957044 | 20:41 |
| opendevreview | Verification of a change to openstack/ironic master failed: Remove direct mapping from API -> DB https://review.opendev.org/c/openstack/ironic/+/956512 | 20:41 |
| opendevreview | Verification of a change to openstack/ironic master failed: Launch vnc proxy with no_fork https://review.opendev.org/c/openstack/ironic/+/957044 | 21:04 |
| * TheJulia hands lemon flavored shortbread cookies to zuul | 21:52 | |
| opendevreview | Verification of a change to openstack/ironic master failed: Remove direct mapping from API -> DB https://review.opendev.org/c/openstack/ironic/+/956512 | 22:09 |
| opendevreview | Steve Baker proposed openstack/networking-generic-switch master: WIP Add security group support to ovs https://review.opendev.org/c/openstack/networking-generic-switch/+/956519 | 22:19 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: Fix the ability to escape service fail https://review.opendev.org/c/openstack/ironic/+/956972 | 22:47 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: Fix the ability to escape service fail https://review.opendev.org/c/openstack/ironic/+/956972 | 22:48 |
| TheJulia | janders: ^^^ I think that covers the concerns and aligns with the earlier discussion, I'll be back in a couple hours, need to run to the market | 22:49 |
| janders | TheJulia thank you! | 22:49 |
| janders | I will have a look and lab-test it and report back | 22:50 |
| TheJulia | its still wip, mainly because my brain broke while trying to figure out some tests claude wrote | 22:50 |
| TheJulia | and make them be sane | 22:50 |
| janders | yeah he does that, I know what you mean | 22:50 |
| janders | enjoy the market :) | 22:50 |
| opendevreview | Merged openstack/ironic master: Launch vnc proxy with no_fork https://review.opendev.org/c/openstack/ironic/+/957044 | 22:53 |
| opendevreview | Jacob Anders proposed openstack/ironic master: Fix servicing abort to respect abortable flag https://review.opendev.org/c/openstack/ironic/+/957189 | 23:08 |
| janders | TheJulia I tested the current revision, LGTM | 23:26 |
| janders | first three test files make sense to me, I'm not entirely sure about management/raid/deploy_utils and counting mock calls (checking if dii is set in test_prepare_agent_boot makes sense) | 23:30 |
| janders | are those the "Claude's special" tests? :) | 23:30 |
| janders | I need to do some gardeing before it gets too hot, back in an hour. One of my orchard trees is a bit unwell and needs some help. | 23:31 |
| TheJulia | janders: its because we're adding a call in the sequence to prepare a ramdisk | 23:58 |
| TheJulia | which ends up trying to save changes to the field and that breaks when folks mock out things like... a node | 23:59 |
| TheJulia | very similar to the problem cardoe is hitting with the mocks and redfish | 23:59 |
| TheJulia | basically, excessive mock usage | 23:59 |
| TheJulia | oooh ahh... four patches lined up in the gate | 23:59 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!