| opendevreview | Merged openstack/ironic master: Clear image cache on deployment failure https://review.opendev.org/c/openstack/ironic/+/957613 | 00:17 |
|---|---|---|
| opendevreview | Merged openstack/ironic master: Use common request_id middleware https://review.opendev.org/c/openstack/ironic/+/970978 | 00:18 |
| opendevreview | Merged openstack/ironic master: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973015 | 00:18 |
| opendevreview | Merged openstack/ironic master: Soft power off before cleaning up inspection ramdisk https://review.opendev.org/c/openstack/ironic/+/970388 | 00:35 |
| opendevreview | Doug Goldstein proposed openstack/ironic stable/2025.2: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973333 | 01:03 |
| opendevreview | Doug Goldstein proposed openstack/ironic bugfix/33.0: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973334 | 01:05 |
| cardoe | cid: I dunno how far back that needs to go | 01:05 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: feat: add 'vendor' and 'category' for port object https://review.opendev.org/c/openstack/python-ironicclient/+/973286 | 01:18 |
| rpittau | good morning ironic! o/ | 07:48 |
| cid | good morning ironic o/ | 08:39 |
| cid | cardoe, that's stable/2024.2 | 08:39 |
| opendevreview | cid proposed openstack/ironic stable/2025.2: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973333 | 09:19 |
| opendevreview | Merged openstack/networking-generic-switch master: Update hacking to 7.0.0 https://review.opendev.org/c/openstack/networking-generic-switch/+/972762 | 09:28 |
| abongale | good morning ironic o/ | 09:32 |
| opendevreview | cid proposed openstack/ironic stable/2025.1: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973355 | 09:38 |
| opendevreview | cid proposed openstack/ironic stable/2025.1: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973355 | 09:40 |
| opendevreview | cid proposed openstack/ironic stable/2024.2: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973356 | 09:41 |
| dtantsur | cardoe: do you by chance use Metal3? I cannot promise that it will be accepted, but I'd be interested in a discussion to add your InspectionRule CR to Metal3. | 12:01 |
| cardoe | I don’t. I’ve tinkered with it in the past. | 12:54 |
| cardoe | We’re likely gonna add stuff to https://k-orc.cloud | 12:55 |
| dtantsur | ah, it's an even better idea | 12:55 |
| dtantsur | the last time I checked they did not have Ironic though | 12:56 |
| cardoe | They don’t. | 12:58 |
| cardoe | We’re gonna add stuff for operators. | 12:59 |
| opendevreview | Merged openstack/ironic-ui master: Imported Translations from Zanata https://review.opendev.org/c/openstack/ironic-ui/+/972615 | 13:01 |
| cardoe | rpittau: when I get that vendor and port change backported to 2025.2 can we cut a client release? | 13:02 |
| rpittau | cardoe: I think so, yeah | 13:03 |
| rpittau | I was planning to do a mass release in 2 weeks, we can anticipate the client though | 13:04 |
| cardoe | Well I meant from the 2025.2 branch. I just want to get it to match the API of the server. | 13:05 |
| cardoe | As soon as I have my coffee I’m going to get the client and the sdk caught up on what we have in master for 2026.1. | 13:05 |
| rpittau | yeah, I got it, but I usually do releases for all supported branches, if needed | 13:06 |
| rpittau | latest release for client is 2 months old | 13:06 |
| cardoe | Right now the latest release says it only supports API 1.96 which was 31.0 or 2025.1 | 13:07 |
| rpittau | yep | 13:08 |
| cardoe | https://review.opendev.org/c/openstack/ironic/+/973294 that’s the API fix as well. I think that’s right. | 13:17 |
| opendevreview | Merged openstack/ironic-prometheus-exporter master: Swap i-p-e over to use dib ipa builds. https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/973298 | 13:43 |
| opendevreview | Merged openstack/ironic stable/2025.2: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973333 | 13:44 |
| cardoe | dtantsur: inspection rules are your bit right? | 14:02 |
| dtantsur | cardoe: wdym "my bit", sorrry? | 14:02 |
| cardoe | You wrote it in ironic-inspector and brought it over? | 14:04 |
| cardoe | I'm trying to write some examples and utilize it. | 14:04 |
| TheJulia | good morning | 14:09 |
| opendevreview | Doug Goldstein proposed openstack/ironic master: add helper tool for testing inspection rules https://review.opendev.org/c/openstack/ironic/+/973381 | 14:09 |
| cardoe | dtantsur: ^ what I'm messing with | 14:09 |
| dtantsur | yeah, I'm to blame for it :D | 14:10 |
| cardoe | I cannot get lt, gt, etc to work. | 14:10 |
| dtantsur | a script to test the rules is a good idea | 14:10 |
| dking | dtantsur: When you have a moment, what is the correct way to set http_basic for BMO connecting to Ironic (IrSO)? Is there not a configmap variable? | 14:12 |
| opendevreview | Merged openstack/ironic stable/2025.1: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973355 | 14:12 |
| cardoe | I think it needs to be a double nested list. But any references to a variable cause it to treat it as a string. | 14:12 |
| opendevreview | Merged openstack/ironic stable/2024.2: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973356 | 14:12 |
| cardoe | TheJulia: morning | 14:12 |
| opendevreview | Merged openstack/ironic bugfix/33.0: Fix order of `disable_ramdisk` validation https://review.opendev.org/c/openstack/ironic/+/973334 | 14:12 |
| dking | Simply setting the username and password didn't seem to get it into the provisioner settings. | 14:13 |
| dtantsur | dking: in BMO 0.12, you can just use IRONIC_NAME/IRONIC_NAMESPACE to point to the IrSO's Ironic object. Otherwise, standard variables should work. | 14:14 |
| dking | dtantsur: Even better! I'll give that a try. | 14:14 |
| opendevreview | Doug Goldstein proposed openstack/ironic-prometheus-exporter stable/2025.2: Swap i-p-e over to use dib ipa builds. https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/973386 | 14:16 |
| dtantsur | cardoe: while I created the initial implementation, I'm less familiar with the current one, sorry | 14:17 |
| cardoe | TheJulia: so the dib ipa didn't backport to 2025.1 without conflict so I skipped it for now. | 14:22 |
| TheJulia | cardoe: much appreciated | 14:22 |
| cardoe | You guys want me to add back E127 from pyflakes for ironic since ruff doesn't do it? | 14:23 |
| cardoe | Or do we maybe wanna just throw in the towel once we branch 2026.1 and just let ruff format the whole code base and us lazy people can just have a save hook that formats it? :-D | 14:24 |
| TheJulia | I sense cardoe is very awake and I'm very asleep | 14:24 |
| cardoe | My kiddo got me up extra early today. | 14:25 |
| TheJulia | My fur child boy, peaches the cat... decided cat gravity had to be applied as soon as my watch started to chime "time to get up" | 14:26 |
| clif | cardoe: do we also need a ironic client patch for portgroup category amd physical_network? | 14:26 |
| cardoe | And I'm trying to put this API / inspect thing to bed so I can focus on the network stuff | 14:26 |
| * TheJulia is extra sleepy now | 14:26 | |
| cardoe | clif: yes we do. But I'm first focused on getting 2025.2 sorted. | 14:27 |
| TheJulia | cardoe: fair enough | 14:27 |
| cardoe | clif: we also need to patch openstacksdk | 14:27 |
| clif | how urgent is it? | 14:27 |
| cardoe | before we cut 2026.1 | 14:27 |
| cardoe | Claude's likely already done the patch | 14:28 |
| TheJulia | so should be merged if possible in ~4 weeks | 14:28 |
| cardoe | I'm just waiting on folks to confirm if I did it correctly for the Port object before I push the Port Group patches. | 14:28 |
| cardoe | So if I get reviews on that part, I'll push the other part. Just trying to not eat every CPU cycle on a patch that might be wrong. | 14:29 |
| cardoe | https://review.opendev.org/c/openstack/ironic/+/973294 is the API side fix | 14:29 |
| cardoe | https://review.opendev.org/c/openstack/python-ironicclient/+/973286 is the client side fix | 14:29 |
| cardoe | https://review.opendev.org/c/openstack/openstacksdk/+/973321 is the openstacksdk fix | 14:30 |
| TheJulia | cardoe: remind me in like an hour, when I'm awake and I'll look | 14:31 |
| cardoe | Not a problem | 14:31 |
| TheJulia | I'm too sleepy to feel confident reviewing code atm | 14:31 |
| cardoe | I wrote those by hand but gave them to claude and told it to do portgroup. | 14:31 |
| cardoe | clif: I'm attempting to use what you've got plus inspection rules to categorize some boxes we've got. We've got 4 NICs in these boxes. 2 of the NICs are on one network fabric (which is plumbed in neutron) and 2 of the NICs are on another fabric which should be ignored by OpenStack today. So just categorizing as "green" and "red" for now. | 14:33 |
| cardoe | What I need is for when a vif attach is run, it should only use the "green" ports. | 14:33 |
| clif | so a filter expression of "port.category == 'green'" with an "attach_port" action should work | 14:34 |
| clif | assuming my code is merged, which it is not yet | 14:35 |
| cardoe | https://github.com/rackerlabs/understack/blob/main/containers/ironic/patches/0001-hack-for-scheduling-purposes-ignore-ports-with-categ.patch that's my extremely offensive hack that I threw into 2025.2 | 14:35 |
| clif | I'm getting close to having something working with vif_attach | 14:35 |
| cardoe | clif: right so once I'm able to get inspection rules working (which is why I did that tester.py like you did for TBN) I'm gonna give your series a go with a rack of this hardware. | 14:36 |
| clif | \o/ that would be awesome, and I'd be happy to address any problems or feedback you have | 14:36 |
| cardoe | If we can get this all fixed by 2026.1 then you, cid, and JayF will get a gold star.... otherwise lumps of coal all around! | 14:37 |
| clif | that's my goal, at least milestone 1-ish of tbn working with vif_attach by 2026.1 | 14:37 |
| cardoe | clif: got an docs for that vif_attach or an example? | 14:37 |
| clif | if you look at https://opendev.org/openstack/ironic/src/branch/master/tools/trait_based_networking/tbn_trait_config.yaml.sample#L17 | 14:39 |
| clif | that attach_port action should get you what you want... if I do my job properly | 14:40 |
| clif | this is a little complicated by the fact that we're stuffing tbn through vif_attach at the moment | 14:41 |
| clif | vif_attach currently selects one port or portgroup to attach to a vif/neutron network | 14:42 |
| clif | but the design of tbn allows an action to specify min and max counts | 14:42 |
| clif | so I'm not sure if we want TBNed vif_attach to support plugging multiple ports to the same network in one vif_attach call | 14:43 |
| clif | or not | 14:43 |
| clif | in my mind, ideally there's some step during node setup/provisioning/whatever where TBN gets a list of ports/portgroups/networks, gets to plan the network, and then sets up everything according to the plan | 14:44 |
| TheJulia | cardoe: I feel like I should be worried https://review.opendev.org/c/openstack/ironic/+/973294/ didn't require a unit test change | 14:44 |
| clif | right now, with the vif_attach way, tbn only gets to consider one network at a time | 14:45 |
| cardoe | TheJulia: you and me both.... | 14:46 |
| TheJulia | hjensas: replied on the vxlan spec to you | 14:46 |
| cardoe | clif: but in the future we want to consider it all? | 14:47 |
| cardoe | TheJulia: I saw hjensas's comments and at a high level I think he's right. | 14:47 |
| clif | imo, yes, but I could be convinced otherwise | 14:47 |
| clif | iiuc TheJulia and JayF wrote the design/spec I'm working against, perhaps their understanding differs | 14:48 |
| TheJulia | cardoe: possibly, that being said that should be a NGS setting | 14:48 |
| TheJulia | clif: huh, what? | 14:48 |
| TheJulia | sorry, I'm confused that there is confusion | 14:48 |
| cardoe | TheJulia: so the multicast group comment I believe is type-5 and that's where I was trying to pitch the new "vxlan" mechanism type driver which allowed the "physical_network" field to be useful to identify different multicast groups... effectively a multicast group is another fabric. | 14:49 |
| cardoe | TheJulia: but any feedback from neutron folks hasn't happened despite us doing the demo and the promise of reviews and feedback | 14:49 |
| TheJulia | Yeah, that was one thing I was quickly finding was that it did appear to all type-5 scenarios where MAC addresses are not used or really considered in the interactions | 14:49 |
| clif | I'm always confused :) | 14:50 |
| TheJulia | cardoe: yeah...... | 14:51 |
| TheJulia | clif: Its more a state of mind and peace :) | 14:51 |
| cardoe | TheJulia: So my thought is we just make this a singular top-level bucket for right now and put that as a known limitation or future expansion. | 14:51 |
| TheJulia | cardoe: oh yeah, at that point its NGS config more than anything else and maybe one day a physical_network to mcast-group mapping table | 14:51 |
| cardoe | Yep | 14:52 |
| clif | right now I'm hooking TBN into VifPortIDMixin.vif_attach, which can work in a limited way | 14:52 |
| TheJulia | The only case I think we're going to struggle with switch side specifics is cases like Dell OS10 where they require vxlan VNIs to be hand mapped to a dedicated "interface" name in the config | 14:53 |
| TheJulia | which can only be numbered in the range 1-65536 | 14:53 |
| clif | but it feels like things would get weird and complicated fast if all of TBN's specced capabilities has to be pushed or accessed through vif_attach only | 14:53 |
| TheJulia | vif_attach is the overall entry point, the request comes inbound which can then be mapped | 14:54 |
| clif | right, but only to one network | 14:55 |
| TheJulia | its a per-call evaluation and mapping though | 14:55 |
| clif | and previously vif_attach's semantics seems to be "map one port or portgroup to one network/vif" | 14:55 |
| clif | and it's becoming "do a bunch of networking actions/planning to one network/vif" | 14:56 |
| clif | which *might* include attaching a port or portgroup, assuming TBN is configured properly | 14:56 |
| TheJulia | That has always been a requirement, imho | 14:57 |
| TheJulia | :) | 14:57 |
| cardoe | Yeah I think we can do it. clif I would say focus on the simple case right now. | 14:57 |
| cardoe | And then we can sit down and walk through the more complex case when we've got a running env. | 14:57 |
| cardoe | I'm happy to stand up a small environment with actual hardware with all of this. | 14:58 |
| clif | I will forge ahead | 14:58 |
| cardoe | Cause that's what I'm gonna use for the VXLAN networking work with TheJulia as well. | 14:58 |
| dking | dtantsur: Thank you very much! That worked beautifully. Now I'm trying to remove all the unnecessary bits from the bmo-configmap, but as I'm looking at it, they all look like Ironic configrations. Would those two be the only variables needed in there? | 14:58 |
| TheJulia | cardoe: okay, so it was the client mappings more than santiization, the object is returned but not really used. That being said, looks like no explicit test was added which makes for an odd escape | 15:01 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Add positive port api category/vendor field test https://review.opendev.org/c/openstack/ironic/+/973396 | 15:06 |
| TheJulia | cardoe: ^^^ | 15:06 |
| TheJulia | I'll second the focus on the simple/happy case. Understand that there needs to be application of logic and we also can't try and handle every misconfiguration with a positive and correctly interpretted outcome. That being said, the simplest is the matching and application for the single action and then taking that further do the needful | 15:10 |
| TheJulia | i.e. create a bond at the attachment time utilizing the existing matching parameters/config | 15:11 |
| TheJulia | ... I think... I'm awake :) | 15:11 |
| cardoe | that makes sense. that's the missing patch. | 15:14 |
| TheJulia | also, the other aspect to consider with vif_attach is we need to make a determine IF we can based upon the information we have and what has already been submitted. We can't try to sort it out later, we need to provide feedback to the user "hey, you asked for the impossible" when the yask | 15:18 |
| TheJulia | s/the yask/they ask/ | 15:18 |
| TheJulia | Uhh... clif it occurs to me we might need to do similar on the portgroups as well? | 15:19 |
| TheJulia | regarding: https://review.opendev.org/c/openstack/ironic/+/973396 | 15:19 |
| clif | Yes, almost certainly, I think cardoe is saying they'll put up more patches for portgroups once the port ones are proved/merged? | 15:27 |
| dtantsur | dking: possibly. If you tell me which you have, I'll tell you which are needed :) | 15:32 |
| dking | dtantsur: It looks like that's it. I was just a bit surprised that it was that easy. Almost nothing I do is stock, so I'm not used to things working so well. Great job! | 15:33 |
| dtantsur | Hehe, I'm happy to hear it :) | 15:33 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: OVN Multinode devstack job https://review.opendev.org/c/openstack/ironic/+/973407 | 15:33 |
| hjensas | TheJulia: thanks, I guess we will find out more once we have a lab. | 15:33 |
| dking | I did have to make a dirty patch to get hostNetwork to set to False, but I'll circle back to that once I get us moved over. | 15:33 |
| dtantsur | Yeah, it's going to be an interesting discussion. We want it to be False too but it does preclude some important cases. I wonder what you come up with. | 15:34 |
| cardoe | TheJulia: yeah I'll add a test for portgroup | 15:36 |
| dking | I just made a new variable for the CRD and read that in. However, I'm still new with go, and for some reason it didn't like the boolean for that particular setting, so I had do a dirty conversion there. I only checked against my local setup, and it works fine there. | 15:37 |
| dtantsur | dking: how do your machines reach Ironic and its httpd if not through the host network? | 15:37 |
| dking | dtantsur: We use mutlus so we can connect directly, which was why we needed to not use hostnetwork. But I still have an ingress for the API stuff, so that seems to work well. | 15:38 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: OVN Multinode devstack job https://review.opendev.org/c/openstack/ironic/+/973407 | 15:44 |
| dtantsur | dking: interesting. What do you use to tell Ironic which IP address to use for callbacks? | 15:45 |
| TheJulia | hjensas: yeah, only real way unfortunately to learn what we don't know | 15:46 |
| dking | dtantsur: Oh, good question. I hadn't made it that far yet, I suppose. I just did an initial ingestion, which only ran inspection, so I'm not sure yet if I'm going to have problems with that. We had been using BMO with the Ironic install, and it seemed to get the right callback URL, and we were still using multus with that, but we were giving it more or less static IPs. | 15:49 |
| dtantsur | dking: inspection: OOB and in-band? | 15:53 |
| dking | dtantsur: OOB | 15:53 |
| dtantsur | I see, yeah. So the actual fun is still ahead | 15:53 |
| dking | dtantsur: Well, let me think. We boot it OOB, but the actual callback might be in-band. | 15:54 |
| dtantsur | Hmm, so inspect_interface=agent or redfish? | 15:54 |
| dking | dtantsur: redfish | 15:54 |
| dtantsur | I see, so you haven't booted anything yet. | 15:55 |
| dking | dtantsur: Well, it booted, but I was probably in between the old and new systems. It did boot into IPA, but we do inspection before we actually have put the node into Ironic. I'm a bit weird with that. | 15:56 |
| dtantsur | Heh, I see. Well, if you did not disable inspection in Metal3, it will try in-band inspection too. | 15:57 |
| dking | So, I'll have to see what happens when we get the whole thing up. I was mostly worried about getting the DHCP/PXE to work, and that worked. BMO is talking to IrSO, so that's good. Next would be getting a node to go all the way through deploy. | 15:57 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: OVN Multinode devstack job https://review.opendev.org/c/openstack/ironic/+/973407 | 15:58 |
| TheJulia | Question to see what folks think: Previously I highlighted a basic need to trigger some sort of "rebind networking" action. I'm curious if folks would see this as a feature of the state machine for an active node, OR if folks see it as a one-off API endpoint that just hides it all. Thoughts? | 16:12 |
| dtantsur | TheJulia: option 3: a service step? | 16:13 |
| TheJulia | Possible! | 16:13 |
| TheJulia | although, that might inherently do it | 16:13 |
| TheJulia | so maybe that is just the option, the noop service step | 16:13 |
| dtantsur | It's not quite noop, is it? :) | 16:13 |
| dtantsur | but it's bikeshedding at this point | 16:14 |
| TheJulia | yeah, true, but yeah | 16:14 |
| TheJulia | you could almost do sleep step and achieve the result | 16:14 |
| dtantsur | At this point, I don't really remember which actions happen when a step does not require IPA. Maybe next to nothing. | 16:15 |
| dtantsur | I'd add a step that is called rebind_networking even if it's implemented as "pass" just to make sure we don't get into trouble if any actions are needed down the road. | 16:16 |
| TheJulia | yeah | 16:16 |
| TheJulia | as long as we act like w'ere going to start up the agent and noop it back out and unwind it all, its all good then | 16:16 |
| * TheJulia walks the corgi overlord | 16:18 | |
| dtantsur | TheJulia: bonus of an explicit step: you don't need to actually boot IPA | 16:18 |
| dtantsur | corgi++ | 16:18 |
| TheJulia | dtantsur: true, true | 16:28 |
| TheJulia | Yeah, a service step is the minimalistic path | 16:52 |
| Sandzwerg[m] | Ohai ironic. We got a arm node for testing and I'm looking for documentation what I need to do to get it working. I assume I need a arm IPA and either something for PXE or a esp (or similar) for virtual-media/HTTP boot? At least at first glance I don't find something mentioning arm in ipa-builder or dibs documentation mentioning arm and I don't see pre-build images. Is there some guidance anywhere? | 17:05 |
| JayF | ARM prebuilt images can be found under ironic-python-agent-builder, I believe | 17:06 |
| JayF | and everything works as expected, look for the *_by_arch settings for a good list of things that'll need to be set for arm | 17:06 |
| JayF | https://tarballs.opendev.org/openstack/ironic-python-agent-builder/dib/files/ has arm64 ipa images | 17:07 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Add a `rebind_networking` service step https://review.opendev.org/c/openstack/ironic/+/973413 | 17:07 |
| TheJulia | dtantsur: ^ Continuity ^ | 17:07 |
| dtantsur | sorry, I'll only be able to check on Monday - trying to balance other urgent requests with packing for the move | 17:09 |
| TheJulia | dtantsur: sure sure, just figured to make claude do some hammering with me giving it many leading questions while it was still fresh in mind | 17:09 |
| dtantsur | Sometimes claude is brilliant, sometimes it cannot fix trivial pep8 errors | 17:15 |
| Sandzwerg[m] | ah then I missed it sorry, thanks for the link. I was looking at https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/ and there is nothing for arm architecture. | 17:15 |
| Sandzwerg[m] | (and it took me quiet a bit to notice the extra "-builder" in the URL. I thought I'd gone blind) | 17:16 |
| TheJulia | dtantsur: "your mission is to execute `tox -epep8` and ensure it passes" | 17:19 |
| JayF | i get frustrated at how bad it is at pep8 sometimes and stop it and fix it myself | 17:19 |
| TheJulia | Interesting... | 17:20 |
| cardoe | Hence why I just wanna use ruff format | 17:39 |
| cardoe | But I personally don't care what the format is... just that its consistent | 17:39 |
| TheJulia | I guess I just beat claude up enough that it learned me | 17:40 |
| dtantsur | The problem is: claude generates code in whatever format it wants, and sometimes gets really confused when the linters says "no" | 17:40 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic-specs master: [WIP] Asynchronous sensor data collection https://review.opendev.org/c/openstack/ironic-specs/+/972754 | 17:46 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic master: Allow aborting deployments in "wait call-back" state https://review.opendev.org/c/openstack/ironic/+/973279 | 17:47 |
| cardoe | I just run ruff format on a hook in other repos and I don't worry about it | 17:47 |
| cardoe | Well since https://review.opendev.org/c/openstack/python-ironicclient/+/973286 is good and once it's +W'd I'll backport it. I'll go ahead and push the port group fixes | 17:47 |
| TheJulia | So yeah, looks like it is more type-5 route handling (the mcast-group) bit. I found a presentation from cisco life noting the nve1 interface and mapping was so the packets get handed off for VRF handling | 17:50 |
| opendevreview | cid proposed openstack/ironic master: Redfish VirtualMedia NFS and SMB/CIFS Support https://review.opendev.org/c/openstack/ironic/+/958505 | 17:53 |
| TheJulia | Claude think it applies to both | 17:56 |
| TheJulia | hjensas: I've got claude going ahead and hammering out mcast-group handling since we *really* don't know what style of configuration the operator has. | 18:15 |
| * cardoe sighs. | 18:45 | |
| cardoe | I regret trying to use inspection rules. | 18:45 |
| cardoe | Can we declare them unstable and unusable so that I can fix them without caring about backwards compat? | 18:46 |
| cardoe | set-port-attribute(port_id, path, value) - Set value on the port identified by a MAC or a UUID. https://docs.openstack.org/ironic/latest/admin/inspection/index.html https://github.com/openstack/ironic/blob/d40ec68facf85273ebd3b9446dd83e490c579583/ironic/common/inspection_rules/actions.py#L341 MAC address huh? | 18:48 |
| cardoe | But it doesn't matter because port_id isn't interpolated so you must hardcode the actual UUID of the port in your inspection rules file. | 18:49 |
| cardoe | loops are performed independently on conditions from actions. e.g. if you had a match in the conditional check there's no way to pass the looped item to the action. | 18:51 |
| TheJulia | your trying to set/match UUIDs? | 19:04 |
| cardoe | No I'm trying to use the set-port-attribute to set category | 19:14 |
| TheJulia | oh, now I understand :( | 19:16 |
| TheJulia | So based upon the vxlan spec as it stands, I've started to work on updates to the ngs patches such that we properly model both configuration paths which we know could exist, as it looks like a few different models are possible for operator configuration | 20:29 |
| TheJulia | Once I have those changed I'll push them up and start on giving that a spin in CI itself, but I expect it will take another day or so to get the patches sorted | 20:30 |
| opendevreview | Merged openstack/python-ironicclient master: feat: add 'vendor' and 'category' for port object https://review.opendev.org/c/openstack/python-ironicclient/+/973286 | 20:53 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient stable/2025.2: feat: add 'vendor' and 'category' for port object https://review.opendev.org/c/openstack/python-ironicclient/+/973439 | 21:15 |
| cardoe | TheJulia from 8 years ago is so adorable. | 21:22 |
| cardoe | "Use a large microversion that we won't exceed." | 21:22 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient stable/2025.2: fix: report compatibility with 2025.2 release of Ironic https://review.opendev.org/c/openstack/python-ironicclient/+/973295 | 21:24 |
| opendevreview | Doug Goldstein proposed openstack/python-ironicclient master: fix: test determining latest API version https://review.opendev.org/c/openstack/python-ironicclient/+/973440 | 21:26 |
| cardoe | I love when I find my commits years later where I make a comment like "this shouldn't happen". Greybeard cardoe is like "oh my sweet summer child." | 21:27 |
| TheJulia | lol | 21:27 |
| cardoe | So that patch is just against the 2025.2 branch which I know we don't like but master has moved on and backporting how master has moved on is wrong cause those changes are for 2026.1 API changes. So I made the patch against 2025.2 and making it match the 2025.2 API. | 21:29 |
| TheJulia | ack | 21:37 |
| TheJulia | err, so I'm conflicted on that because it looks like nothing else got added. I'm not sure we should actually merge the version bump at this point on the stable branch | 21:40 |
| cardoe | Well it's just to allow you to request 1.101 which is the release mapping API for 2025.2 | 21:45 |
| cardoe | You cannot specify via the CLI args any value larger than that. 96 was the 2025.1 value | 21:46 |
| TheJulia | I guess the one aspect which makes it sort of a bugfix is 1.98 | 21:49 |
| TheJulia | 1.96 is introspection rules, its a cap in the rendered page :\ | 21:49 |
| TheJulia | s/cap/gap | 21:50 |
| cardoe | well I cannot even read/write port description, vendor, category from the API without that. | 22:08 |
| cardoe | Even if my server supports it and I request the correct API version | 22:09 |
| opendevreview | Merged openstack/ironic-prometheus-exporter stable/2025.2: Swap i-p-e over to use dib ipa builds. https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/973386 | 23:07 |
| opendevreview | Merged openstack/bifrost master: add an OCI artifact registry https://review.opendev.org/c/openstack/bifrost/+/961388 | 23:33 |
| opendevreview | Merged openstack/bifrost master: bifrost-registry-install: install the ORAS client https://review.opendev.org/c/openstack/bifrost/+/968355 | 23:33 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!