| opendevreview | Steve Baker proposed openstack/ironic master: Register oslo.service opts in prepare_command for spawn workers https://review.opendev.org/c/openstack/ironic/+/993062 | 00:20 |
|---|---|---|
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Add RestconfSwitch base class for HTTP transport https://review.opendev.org/c/openstack/networking-generic-switch/+/992887 | 07:24 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Add RestconfOpenConfigSwitch driver https://review.opendev.org/c/openstack/networking-generic-switch/+/992888 | 07:24 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Add RESTCONF documentation https://review.opendev.org/c/openstack/networking-generic-switch/+/992889 | 07:24 |
| opendevreview | Pierre Riteau proposed openstack/tenks master: Switch to 2026.1 upper constraints temporarily https://review.opendev.org/c/openstack/tenks/+/993082 | 08:04 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Rename netconf_models to yang_models https://review.opendev.org/c/openstack/networking-generic-switch/+/993090 | 09:06 |
| dtantsur | JayF: s/metal3/standalone/ please. You make it sound like we're developing metal3-exclusive features, which is not the case. | 10:37 |
| dtantsur | JayF: someone needs to check if non-neutron networking can be used with neutron DHCP plugin. Fortunately, we never got to deprecating DHCP plugins :) | 10:37 |
| dtantsur | Let's see if Claude can be this "someone" | 10:39 |
| dtantsur | JayF: Claude thinks you're out of luck: https://paste.opendev.org/show/byDtqdtE2bMNZxcp25As/ (I have *not* verified any of the claims here) | 10:47 |
| dtantsur | I'm curious why you wouldn't use n-g-s as an ML2 plugin if you have Neutron anyway though. | 10:47 |
| opendevreview | Mithun Krishnan Umesan proposed openstack/networking-baremetal master: Upgrade OVN SSL connections to TLS 1.3 with hybrid PQC key exchange https://review.opendev.org/c/openstack/networking-baremetal/+/992495 | 11:53 |
| opendevreview | Verification of a change to openstack/ironic unmaintained/2023.1 failed: security: Use sandbox rendering for jinja2 https://review.opendev.org/c/openstack/ironic/+/987778 | 11:54 |
| opendevreview | Pierre Riteau proposed openstack/tenks master: Switch to 2026.1 upper constraints temporarily https://review.opendev.org/c/openstack/tenks/+/993082 | 12:18 |
| *** dking is now known as Guest11231 | 12:20 | |
| *** Guest11231 is now known as dking | 12:21 | |
| dking | dtantsur: Would you happen to be in this morning? | 12:26 |
| dtantsur | dking: hi! sorry, was having lunch. | 12:52 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent stable/2025.2: ci: Pin setuptools to a range that still ships https://review.opendev.org/c/openstack/ironic-python-agent/+/993107 | 12:55 |
| dking | dtantsur: No worries. Thank you for responding. I never did get a response in slack, and I was wondering whether I could get some help regarding errors regarding the "baremetal-operator-controller-manager-metrics-" service. | 13:04 |
| dtantsur | dking: yeah, a lot of Ericsson folks are absent, so the slack is a bit quiet | 13:04 |
| dking | dtantsur: After we upgraded our BMO a while ago, we started getting errors for the metrics service, and when I looked it it, it seems it was due to kube-rbac-proxy and the way the certificates are handled. It looks like I would need to know how to get the cert file that the manager is using. | 13:10 |
| dtantsur | dking: from what to what version? | 13:16 |
| dking | The old version was quite old. Currently, we're doing BMO v0.12.0 and kube-rbac-proxy at v0.15.0. | 13:20 |
| TheJulia | dtantsur: I think he might be pondering a world without neutron | 13:23 |
| dtantsur | TheJulia: then how is it different from Metal3 case? | 13:23 |
| TheJulia | Outside of the ecochamber, neutron folks seem to be blissfully unaware of neutron network modeling perceptions and how that is driving the way folks are looking at it | 13:24 |
| dtantsur | echochambers-- | 13:24 |
| TheJulia | dtantsur: they wouldn't be using metal3 at all, its pure standalone with whatever wrapper they determine they need for their use case | 13:24 |
| TheJulia | at least, that is the way I'm reading the discussion now | 13:25 |
| dtantsur | TheJulia: sure, sure, but JayF is claiming the current implementation is done with Metal3 in mind, and it's.. not? | 13:25 |
| dtantsur | If the message is "we need a standalone IPAM", I'm all for it :) | 13:25 |
| TheJulia | I'd argue it might not be our place, most shops have their own IPAMs already | 13:25 |
| TheJulia | the big challenge neutron had prior was that it insisted on being the IPAM as well | 13:26 |
| TheJulia | and many operators were like "I already have processes, tools, and procedures | 13:26 |
| TheJulia | " | 13:26 |
| dtantsur | True. But if you have IPAM, all you need is a glue to populate network_data in two places, right? | 13:26 |
| dtantsur | (which is exactly the same problem we have in Metal3 btw) | 13:26 |
| TheJulia | or one place through ironic | 13:27 |
| TheJulia | specifically record recording for data generation | 13:27 |
| TheJulia | realistically, the risk of jumping to modeling conclusions is where we're at and Jay is still trying to get his bearings and perception. We don't know his constraints/requirements either | 13:28 |
| TheJulia | (I guess I'm saying it might be a better dialog to have when Jay is awake/alive/caffinated) | 13:29 |
| * TheJulia begins the sacred task of caffination | 13:30 | |
| TheJulia | I wonder if https://www.teepublic.com/hoodie/2624841-i-am-one-with-the-coffee-and-the-coffee-is-with-me can be on a t-shirt.... | 13:32 |
| dtantsur | ++ would be great | 13:32 |
| dtantsur | dking: https://github.com/metal3-io/baremetal-operator/pull/2102. Kill kube-rbac-proxy with fire, it seems. | 13:39 |
| dking | dtantsur: Well, that would do it. I suppose that we need to update and make sure that we have the right CRDs. Thank you very much. | 13:51 |
| JayF | dtantsur: It's clearly built for a DHCP-first environment OR an environment with a coordinating higher level tool -- our interfaces are structured in a way where it's nearly impossible for a instance-deployer to setup their own static IPs without intimate knowledge of the node's networking | 13:56 |
| JayF | dtantsur: I abbreviated that to "built for metal3" | 13:56 |
| TheJulia | more like dhcp-less && coordinated at a higher level | 13:57 |
| dtantsur | JayF: I'm just pointing out that Ironic standalone is entirely like that. We've never had a solid IPAM story, with or without switch management. | 13:57 |
| JayF | and based on your observations (Which match what I would expect given my rapid-digging yesterday) it doesn't even come with the DHCP server :) | 13:57 |
| JayF | dtantsur: I'm not wanting Ironic to IPAM. | 13:58 |
| JayF | dtantsur: I want to feed ironic an IP/netmask/dns server in the same port.extra as the switchport, and then Ironic injecting that into the network_data | 13:58 |
| TheJulia | you want to simplify the carrying of data down to something like a vif then ? | 13:58 |
| JayF | this doesn't make Ironic the IPAM, it turns "tenant" IPs into something that -- if you use that capability -- are provisioned at the same time the port is | 13:58 |
| TheJulia | so the ipam/inventory management has and maintains it ? | 13:59 |
| JayF | so later deployments don't need network details | 13:59 |
| dtantsur | Understood. I think what you're talking about is yet another thing we skipped by going down the port.extra path. | 13:59 |
| JayF | It would 1000% be outta scope for Ironic to care about what the IP address field (for instance) has, other than making sure it's an IP | 13:59 |
| TheJulia | at a cursory level, its not a bad idea | 13:59 |
| JayF | dtantsur: yeah none of this chat is "we built a bad thing" or even "we built half a thing", if anything it's more like "we build enough good stuff that now my folks are interested and asking me to find the sharp edges for our use case" :D | 14:00 |
| * dtantsur nods | 14:01 | |
| dtantsur | It's the same for us. While metal3 has an IPAM, it's bolted on CAPI API and is barely usable without it. | 14:01 |
| dtantsur | And it does not integrate with node.network_data for inspection/provisioning | 14:01 |
| dtantsur | Midcycle topic? | 14:01 |
| JayF | Many places I've worked have had kinda a hub/spoke model for clouds. One big central cloud, a bunch of smaller satellite sites for various use cases | 14:02 |
| JayF | CDN, networking geography, etc | 14:02 |
| dtantsur | My place too :) | 14:02 |
| JayF | I think Ironic+Ironic Networking is about 5 feet from becoming the best tool for that use case :D | 14:02 |
| JayF | (for the smaller, satellite sites) | 14:03 |
| JayF | and yes, americans use imperial measurements for story points, too /s | 14:03 |
| dtantsur | We need to up the game and use different measurements themselves instead of story points! | 14:05 |
| dtantsur | like, instead of S/M/L, you get inch, foot, yard, mile, whatever | 14:05 |
| JayF | so if something's really small, it can be a task, then we'll move up to story, epic, project, program, company, nation-state, civilization, planet, universe | 14:07 |
| JayF | lol | 14:07 |
| dtantsur | ROFL | 14:07 |
| TheJulia | so where does the retirement catameran sit in that list? | 14:12 |
| TheJulia | is that a program?!? | 14:12 |
| JayF | listen, that's a ServiceNOW term | 14:13 |
| JayF | we only use JIRA in this house | 14:13 |
| JayF | /s | 14:13 |
| JayF | everyone knows ServiceNOW goes from bicycle->transgalactic generational spacecraft (transportation devices by size) | 14:13 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Add NetconfOpenConfigSwitch driver https://review.opendev.org/c/openstack/networking-generic-switch/+/990061 | 14:21 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Add NETCONF OpenConfig driver documentation https://review.opendev.org/c/openstack/networking-generic-switch/+/990062 | 14:21 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Add trunk subport for NETCONF OpenConfig driver https://review.opendev.org/c/openstack/networking-generic-switch/+/991458 | 14:21 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Netconf: Document Neutron trunk port support https://review.opendev.org/c/openstack/networking-generic-switch/+/991459 | 14:21 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Refactor: extract OpenConfigModelMixin https://review.opendev.org/c/openstack/networking-generic-switch/+/992884 | 14:22 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Add to_restconf_dict() methods to OpenConfig model https://review.opendev.org/c/openstack/networking-generic-switch/+/992885 | 14:22 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: restconf: add path helpers and resource_path util https://review.opendev.org/c/openstack/networking-generic-switch/+/992886 | 14:22 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Add RestconfSwitch base class for HTTP transport https://review.opendev.org/c/openstack/networking-generic-switch/+/992887 | 14:22 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Add RestconfOpenConfigSwitch driver https://review.opendev.org/c/openstack/networking-generic-switch/+/992888 | 14:22 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Add RESTCONF documentation https://review.opendev.org/c/openstack/networking-generic-switch/+/992889 | 14:22 |
| opendevreview | Harald Jensås proposed openstack/networking-generic-switch master: Rename netconf_models to yang_models https://review.opendev.org/c/openstack/networking-generic-switch/+/993090 | 14:22 |
| clif | JayF: https://review.opendev.org/c/openstack/ironic-python-agent/+/993107 does this look right? | 14:28 |
| clif | It passes, but the test that failed the backport is not represented in the tests run on that change | 14:28 |
| JayF | oooh | 14:28 |
| JayF | Take your backport, add a trailer: "Depends-on: https://[snip]/993107" | 14:28 |
| JayF | and it'll stack em | 14:29 |
| hjensas | Work should be measured in volume, fluid ounce, gill, *pint*, quart, gallon :) | 14:29 |
| JayF | oh, nevermind, that's wrong | 14:29 |
| JayF | it won't work in the same repo | 14:29 |
| JayF | you'll have to actually stack them (git review -d [ci fix], git review -x [stable fix], git review) | 14:29 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent stable/2025.2: ci: Pin setuptools to a range that still ships https://review.opendev.org/c/openstack/ironic-python-agent/+/993107 | 14:32 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent stable/2025.2: Add a flag to disable installing bootloaders https://review.opendev.org/c/openstack/ironic-python-agent/+/993020 | 14:32 |
| clif | so I'll have to stack each backport on top of this change | 14:32 |
| JayF | well, if it works | 14:33 |
| clif | yea | 14:33 |
| JayF | we can just push through the CI change first | 14:33 |
| JayF | then recheck your stable changes | 14:33 |
| JayF | I only ever really stack them to validate it's the fix needed | 14:33 |
| clif | that works | 14:33 |
| JayF | given you are just testing for the docs job, if you don't wanna wait 2 hours for integration tests, go zuul.opendev.org -> openstack [status] -> put the change # 993020 in the box and hit enter | 14:36 |
| JayF | you can see tests run and when you see docs go green, you can proliferate the fixes down | 14:36 |
| opendevreview | Himanshu Roy proposed openstack/ironic master: Add releasenote for disallow-steps feature https://review.opendev.org/c/openstack/ironic/+/993131 | 14:46 |
| opendevreview | Himanshu Roy proposed openstack/ironic master: Add releasenote for disallow-steps feature https://review.opendev.org/c/openstack/ironic/+/993131 | 14:47 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent stable/2025.1: Add a flag to disable installing bootloaders https://review.opendev.org/c/openstack/ironic-python-agent/+/993024 | 15:01 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent stable/2025.1: ci: Pin setuptools to a range that still ships https://review.opendev.org/c/openstack/ironic-python-agent/+/993136 | 15:01 |
| opendevreview | Will Szumski proposed openstack/tenks master: CI: Make aarch64 jobs experimental https://review.opendev.org/c/openstack/tenks/+/993138 | 15:07 |
| opendevreview | Will Szumski proposed openstack/tenks master: CI: Make aarch64 jobs experimental https://review.opendev.org/c/openstack/tenks/+/993138 | 15:13 |
| clif | I must've missed something because this failed with the same issue https://zuul.opendev.org/t/openstack/build/4c35b76d54fb4c6386ca0fadd674af18 | 15:21 |
| clif | it looks like the setuptools it grabbed was 82.0.0 so it falls in line with the range set | 15:23 |
| dtantsur | Failed to send baremetal.port.create.start notification for port f64d726b-9e9e-4a2a-844b-34062a15b2e5 with level info, notification method PortCRUDNotification, payload method PortCRUDPayload, error Object port doesn't have the field "available_for_dynamic_portgroup" required for populating notification schema key "available_for_dynamic_portgroup" | 15:28 |
| dtantsur | Noticed ^^ in metal3 logs, anyone has a clue? | 15:28 |
| clif | that's a new field we added in relation to trait based networking | 15:36 |
| clif | did migrations run? | 15:39 |
| clif | iirc the change to add it followed the exact same structure as adding the new vendor and category fields to port{group}s | 15:40 |
| TheJulia | It maybe that code expects the field on the notification…. That seems like a bug | 15:44 |
| clif | could this be related to release_mapping shenanigans? | 15:44 |
| TheJulia | More likely, different interfaces somehow playing into the flow resulting in that | 15:45 |
| TheJulia | But, interesting notifications are on apparently?! | 15:45 |
| clif | 33.0 doesn't have the latest port version listed, which is what includes 'available_for_dynamic_portgroup' in port | 15:45 |
| TheJulia | Dmitry is likely running 37.0 | 15:46 |
| clif | oh for some reason I was looking at an old version of release_mappings | 15:50 |
| clif | not master | 15:50 |
| dtantsur | yeah, I'm very close to master | 16:00 |
| cardoe | so what's ironic? | 16:05 |
| cardoe | in other words, I'm finally at my desk | 16:06 |
| opendevreview | Merged openstack/tenks master: CI: Make aarch64 jobs experimental https://review.opendev.org/c/openstack/tenks/+/993138 | 16:07 |
| opendevreview | Pierre Riteau proposed openstack/tenks master: Switch to 2026.1 upper constraints temporarily https://review.opendev.org/c/openstack/tenks/+/993082 | 16:14 |
| opendevreview | Merged openstack/ironic-python-agent stable/2025.2: ci: Pin setuptools to a range that still ships https://review.opendev.org/c/openstack/ironic-python-agent/+/993107 | 16:21 |
| TheJulia | cardoe: welcome back! | 16:22 |
| TheJulia | cardoe: we've assigned all work to you, congrats! | 16:22 |
| TheJulia | </joking!> | 16:22 |
| cardoe | <insert I'm in danger meme> | 16:36 |
| TheJulia | lol | 16:40 |
| TheJulia | so, I'd really love to discuss nvmeof, if that doesn't make you want to pack up and run for the hills | 16:45 |
| cardoe | Not for installation like the current implementation is for I assume | 16:47 |
| JayF | It kinda does :). But mainly from a "we gotta be careful to not create security vulns while resolving them" standpoint | 16:47 |
| * dtantsur tries to switch from Go to Python | 16:49 | |
| dtantsur | c'mon brain, you can do it | 16:49 |
| * TheJulia offers dtantsur chocolate chip cookies | 16:51 | |
| dtantsur | coooookiiies! | 16:51 |
| TheJulia | cardoe: Kind of what JayF said, I guess I've got a number of challenges I've sort of drifted into in my mind and I would <3 a slightly wider discussion with folks doing simlar or interested in similar to see what thought are. For example, it looks like HPE gear entirely lacks the ability to set credentials for NVMeoF/TCP.... *facepalm* | 16:52 |
| TheJulia | Where as dell, has undocumented and confusing fields | 16:53 |
| TheJulia | And I get it, its sort of emerging case stuff | 16:53 |
| * TheJulia is splunking through HPE BMCs at the moment | 17:22 | |
| * TheJulia thinks we scared cardoe away | 17:36 | |
| dtantsur | It's been an exhausting week, see you on Monday o/ | 17:50 |
| TheJulia | have a good weekend! | 17:53 |
| opendevreview | Merged openstack/ironic stable/2026.1: fix: skip storage controllers without Volumes link https://review.opendev.org/c/openstack/ironic/+/990116 | 18:14 |
| clif | JayF: I think we need to patch ironic-python-agent-builder too to pin back its setuptools? | 18:15 |
| clif | https://zuul.opendev.org/t/openstack/build/882ec0fb6a8444328acb31d6a755e6c1/log/job-output.txt#25182 here you can see it downloading setuptools-82.0.1 which is beyond what is pinned in ipa tox.ini | 18:19 |
| clif | and it errors out in setuptools with ModuleNotFoundError: No module named 'pkg_resources' again | 18:19 |
| TheJulia | ugh | 18:20 |
| clif | the joyous work continues | 18:23 |
| TheJulia | we need something like "ad astra per aspera" as our motto ;) | 18:25 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent-builder stable/2025.2: ci: Pin setuptools to a range that still ships https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/993158 | 18:26 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent stable/2025.1: Add a flag to disable installing bootloaders https://review.opendev.org/c/openstack/ironic-python-agent/+/993024 | 18:27 |
| clif | erg that's wrong | 18:27 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent stable/2025.1: Add a flag to disable installing bootloaders https://review.opendev.org/c/openstack/ironic-python-agent/+/993024 | 18:27 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent stable/2025.2: Add a flag to disable installing bootloaders https://review.opendev.org/c/openstack/ironic-python-agent/+/993020 | 18:28 |
| opendevreview | Julia Kreger proposed openstack/ironic-specs master: Crazy idea: RCOE Enabled BMaaS https://review.opendev.org/c/openstack/ironic-specs/+/990413 | 18:30 |
| JayF | clif: keep going down the rabbithole, I assure you it will eventually end and you can climb back up the chain of fixes :| | 18:37 |
| clif | are there other repos I should be aware of that may need their setuptools pinned back? | 18:37 |
| opendevreview | Merged openstack/tenks master: Switch to 2026.1 upper constraints temporarily https://review.opendev.org/c/openstack/tenks/+/993082 | 18:38 |
| clif | do y'all know how build-tinyipa.sh gets its requirements.txt or how to pin back what it downloads? | 19:03 |
| clif | it looks like I'd have to pin back setuptools inside ipa-builder's requirements.txt in order to have that take effect for build-tinyipa.sh | 19:05 |
| clif | but that doesn't follow the shape of the change for ironic and IPA, is that OK? | 19:05 |
| clif | or maybe I'd have to do it inside IPA's requirements.txt | 19:06 |
| clif | is that kosher? | 19:08 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent stable/2025.2: Add a flag to disable installing bootloaders https://review.opendev.org/c/openstack/ironic-python-agent/+/993020 | 19:12 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent stable/2025.2: Pin setuptools inside requirements.txt https://review.opendev.org/c/openstack/ironic-python-agent/+/993164 | 19:12 |
| JayF | clif: If we were going to pin in requirements.txt, it's better to do it in ipa-builder IMO | 19:20 |
| clif | how? | 19:20 |
| clif | modify the copy of IPA's requirements.txt it makes? | 19:21 |
| JayF | ooooh | 19:21 |
| JayF | I see what you're saying | 19:21 |
| JayF | IPA-builder is "installable" as a python application as well | 19:21 |
| JayF | so I was looking in the wrong spot | 19:22 |
| JayF | clif: so 2025.2, is it tinyipa only or tinyipa+dib builds? | 19:22 |
| clif | not sure, I'm just running down the error I'm currently seeing in CI | 19:23 |
| JayF | OK this appears to be in build-tinyipa | 19:24 |
| cardoe | TheJulia: so NVMe? | 19:24 |
| JayF | https://opendev.org/openstack/ironic-python-agent-builder/src/branch/stable/2025.2/tinyipa/build-tinyipa.sh#L145 | 19:25 |
| JayF | we are already munging the requirements.txt there | 19:25 |
| JayF | I'd be tempted to make that add a setuptools pin | 19:25 |
| TheJulia | heh, so my brain is so on nvme that I thought I read that line as starting at nvmexpress.org and ending with build-tinyipa | 19:26 |
| clif | copying == munging? | 19:26 |
| TheJulia | inquiring minds, why are we still building tinyipa on 2025.2? Didn't we kill it by then?! | 19:26 |
| JayF | well, tbh, I misread the LN:147 code as being modifications to that library | 19:27 |
| JayF | TheJulia: I haven't asked that question, I'm just reading logs and troubleshooting while eating lunch | 19:27 |
| TheJulia | I was just nomming celery because apparently I need to not eat or eat like a rabbit only and exercise more than I already do :( | 19:28 |
| * TheJulia rages at doctors ignoring issues | 19:28 | |
| * TheJulia regains composure | 19:28 | |
| JayF | clif: I think that's still a good place to do it even though we aren't modifying it directly there, but TheJulia's implied question of "can we just kill tinyipa based jobs on 2025.2" is a good one | 19:29 |
| JayF | the problem with that is that if we published tinyipa for 2025.2 | 19:29 |
| JayF | don't we owe people an updated ramdisk? | 19:29 |
| * TheJulia is all for declaring it as tinyipa's ides of march | 19:29 | |
| JayF | even if we have been screaming to not use it outside of CI for a decade | 19:29 |
| * TheJulia wonders if weveryone has their Pugio's ready! | 19:30 | |
| TheJulia | heh | 19:30 |
| TheJulia | cardoe: yeah, so I'm trying to rationalize into what would be best to exist upstream for NVMeoF/TCP support | 19:34 |
| TheJulia | part of what I'm also stuggling to rationalize is a model where everything makes sense and is also cross-vendor | 19:36 |
| TheJulia | but... maybe that means I just need to push the DMTF harder | 19:36 |
| JayF | I think we have plenty of evidence now that implementing features on half-ass-implementations of Redfish interfaces just lead to Ironic getting blamed when things go wrong... | 19:37 |
| JayF | That leads me to a path of instead of working really hard to make something that barely works work, maybe convince the DMTF to do something about the half-ass implementations first | 19:37 |
| TheJulia | I honestly think I'm kind of okay with dell's model but getting it to a better place across vendors is the needful | 19:38 |
| TheJulia | Well my challenge is customers wanting to get on a track now so that train can arrive in say, 18 months | 19:38 |
| TheJulia | because I think they grok just how long that takes | 19:38 |
| JayF | I mean, I can understand the pressures of that, but they need to get the vendors+DMTF on board before us :/ | 19:39 |
| JayF | and/or pad that number if it's now your job lol | 19:39 |
| TheJulia | well, where the DMTF least left it as an an oem oriented bios setting, only 2 vendors even do that, hpe being even more weirdly so | 19:39 |
| TheJulia | And I think that was sort of their base mistake | 19:40 |
| TheJulia | because the vendors didn't really take full initiative | 19:40 |
| TheJulia | Also, emerging technology | 19:40 |
| TheJulia | adding authentication requriements when "storage" is just a "storage network and it works" | 19:40 |
| TheJulia | is dramatic shifts too | 19:40 |
| TheJulia | but yeah, table stakes and if its now my job... | 19:41 |
| TheJulia | dunno | 19:41 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent-builder stable/2025.2: Pin setuptools in the requirements.txt copied from IPA https://review.opendev.org/c/openstack/ironic-python-agent-builder/+/993176 | 19:41 |
| opendevreview | Clif Houck proposed openstack/ironic-python-agent stable/2025.2: Add a flag to disable installing bootloaders https://review.opendev.org/c/openstack/ironic-python-agent/+/993020 | 19:43 |
| cardoe | TheJulia: meetpad? | 19:45 |
| cardoe | And then we can summarize? | 19:45 |
| TheJulia | sure, fwiw, I've been noodling a spec on the topic | 19:45 |
| * TheJulia sends claude on a mission which may take a while | 19:46 | |
| TheJulia | https://meetpad.opendev.org/ironic-nvme | 19:47 |
| JayF | TheJulia: I've just gotten a pretty strong signal from users, my downstream and others, that they have been trained to avoid advanced features that interact with redfish because you cannot trust they will work with new hardware | 19:50 |
| JayF | that's not exactly "our fault", but we are the messengers of that bad news everytime, and we're often also the folks who said "look at the cool thing we can do" | 19:51 |
| JayF | IDK how to manage that, but I think in the past we just haven't at all, and IDK how much longer that'll be OK | 19:51 |
| JayF | clif: TheJulia: dtantsur: RFR https://review.opendev.org/c/openstack/security-doc/+/993182 --- after review, I intend to announce this on Monday. | 20:46 |
| TheJulia | Yeah, I'm not super thrilled with one of the vendors right now | 20:46 |
| TheJulia | regarding their redfish | 20:46 |
| JayF | ^ do not review is wrong | 20:48 |
| JayF | this belongs in a different OSSA, I have no idea why my notes said to revise this one | 20:48 |
| JayF | clif: TheJulia: dtantsur: attempt #2: [OSSA-2026-017] Errata 1: fix parsing edge cases https://review.opendev.org/c/openstack/ossa/+/993185 actually errata'ing the correct change /o\ | 20:59 |
| JayF | https://review.opendev.org/c/openstack/ironic/+/986418 could use a +2a | 21:21 |
| TheJulia | so, cardoe has convinced me that maybe a first pass on anti-redfish is the way | 21:22 |
| TheJulia | but I still have a reminder for DMTF discussion | 21:22 |
| TheJulia | :) | 21:22 |
| cardoe | yeah absolutely think we'll need some DMTF follow on here | 21:22 |
| cardoe | But we came to the conclusion that first pass might be the secondary volume attachment flowing smoothly and storing the data because that'll unlock the primitives for the redfish way. | 21:23 |
| cardoe | JayF: I gave it a +2 | 21:23 |
| TheJulia | and fwiw, I have made them aware that this is a focus area, so we shall see | 21:23 |
| JayF | https://review.opendev.org/c/openstack/ironic/+/991384 and the one under it needs approval too | 21:24 |
| JayF | https://review.opendev.org/c/openstack/ironic/+/991385 (the one under it) | 21:24 |
| JayF | I'm probably going to hang it up here, I'll babysit the um/202x.1 branches and recheck/fix until we get to everything being merged there | 21:24 |
| cardoe | When you get some time next week, JayF if you can gimme some feedback on https://review.opendev.org/c/openstack/ironic/+/986233 | 21:24 |
| JayF | I suspect my monday is going to be eaten working with clif to similarly clean up ipa :( | 21:25 |
| JayF | cardoe: +2a | 21:25 |
| clif | JayF: it failed successfully: Failed to install a bootloader when deploying node 699e1929-2f0e-4042-bcde-015b154040dd: Install of legacy BIOS bootloaders disabled by CONF.enable_bios_bootloader_install as part of CVE-2026-43003 mitigation. | 21:50 |
| clif | unless I need to flip the backport to defaulting to allow installing a bootloader | 21:51 |
| JayF | clif: so two choices here: | 22:06 |
| JayF | clif: 1) Create a change for that branch, subject prefix [stable-only] [ci], that adds the ability to flip that config in devstack via env variable, and set that env variable on jobs that need the partition image support enabled | 22:07 |
| JayF | clif: 2) Remove the partition image job. | 22:07 |
| JayF | TheJulia: ^ how much do we care about partition image integration testing on 2025.2? | 22:08 |
| JayF | (and older) | 22:08 |
| TheJulia | I don't | 22:08 |
| * TheJulia fires up the torch and hands it to cliff | 22:08 | |
| TheJulia | clif | 22:08 |
| TheJulia | "Can't be stuck if it is molten" | 22:09 |
| JayF | clif: Feel free to do a [stable-only] [ci] Disable partition image testing change and remove those jobs from the check and gate queues in zuul.d/ironic-jobs.yaml | 22:09 |
| TheJulia | +++++++ | 22:09 |
| JayF | if you want a gold star | 22:09 |
| JayF | push a version of the backport with the default flipped | 22:09 |
| JayF | and ensure it passes CI | 22:09 |
| JayF | (as a throwaway, testing-only change in CI) | 22:10 |
| JayF | (not suggesting you change the default in a merged version) | 22:10 |
| clif | I think this is a job for monday clif if nobody minds | 22:11 |
| clif | since its past five on a friday | 22:11 |
| JayF | I think I said I was calling it a day around :41 minutes ago :D | 22:11 |
| JayF | it's just like, the midwest/southern goodbye | 22:11 |
| JayF | now I'm actually going to close IRC and have a friday evening o/ | 22:12 |
| clif | o/ glhf | 22:16 |
| opendevreview | Merged openstack/ironic unmaintained/2023.1: security: move file url validation up into deploy_utils main path https://review.opendev.org/c/openstack/ironic/+/988480 | 22:20 |
| TheJulia | I'm heading out in a little bit myself | 22:24 |
| opendevreview | Merged openstack/ironic unmaintained/2023.1: security: validate molds url against swift in keystone catalog https://review.opendev.org/c/openstack/ironic/+/986817 | 22:31 |
| opendevreview | Verification of a change to openstack/ironic unmaintained/2023.1 failed: Shell-quote console command passed to `socat` https://review.opendev.org/c/openstack/ironic/+/986418 | 22:31 |
| opendevreview | Merged openstack/ironic master: doc: highlight firmware interface and deprecate management for updates https://review.opendev.org/c/openstack/ironic/+/986233 | 23:09 |
| opendevreview | Merged openstack/ironic unmaintained/2024.1: security: directory transversal ISO9660 support https://review.opendev.org/c/openstack/ironic/+/991384 | 23:09 |
| opendevreview | Merged openstack/ironic unmaintained/2024.1: security: disable driver_info level pxe_template override https://review.opendev.org/c/openstack/ironic/+/991385 | 23:18 |
| opendevreview | Merged openstack/ironic master: api: Add schema for events API https://review.opendev.org/c/openstack/ironic/+/959880 | 23:44 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!