| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-06-12 | |||
| 14:40:25 | sean-k-mooney | so there are 16 patches i think for nova outstanding. do you stil have another batch on your github once this next bactch is done or is this the full set - any followups needed | |
| 14:41:58 | sean-k-mooney | stephenfin: context im tryign to decied if i think we can get this compleded by m2 or not | |
| 14:42:23 | sean-k-mooney | it woudl be nice if we can but im not sure how much review time i can dedicate between now and then | |
| 14:43:29 | stephenfin | Ah, there's quite a few patches still outstanding. 20 in total, targeting 14 APIs (I've split the servers one up into 6 patches, as you've already seen) | |
| 14:43:55 | stephenfin | When is m2? Assuming it's less than ~6 weeks away, that sounds optimistic | |
| 14:44:30 | sean-k-mooney | so the 16 that are open and ~20 after. ok well i hope we can land the first batch of 16 before m2 and we can then continut with the rest. its july 3rd i think | |
| 14:44:48 | sean-k-mooney | so 3 weeks time | |
| 14:45:29 | sean-k-mooney | that not a deadline by any means i just wanted to knwo were we were since i knew you proviosly had more patches that were pending | |
| 14:46:52 | sean-k-mooney | i dont knwo what gmaan PTO plans are like and im also aware that they have the policy work to do this cycle so im just trying to guage it we are likely to get this compelte this cyle. i think we are still on track to do that | |
| 14:47:06 | opendevreview | sean mooney proposed openstack/nova master: [DNM] testing rdo experimental jobs https://review.opendev.org/c/openstack/nova/+/927762 | |
| 14:48:02 | sean-k-mooney | gibi: as an fyi whiel that "works" we get some volume related test failures if i recall corectly | |
| 14:48:12 | sean-k-mooney | im not really sure why | |
| 14:49:19 | sean-k-mooney | gibi: ^ we also need to clean up the fr2 branch of the operator to remvoe the duplicate definiton of the pragm that may or may not cause that job to fail | |
| 14:49:52 | sean-k-mooney | gibi: if it does nto work as exepcted let me knwo an ill take a quick look | |
| 14:53:36 | gibi | sean-k-mooney: thanks. I just told the story about this possibility to artom and then I wanted to see if it still works | |
| 14:53:40 | gibi | I will report back | |
| 14:54:18 | sean-k-mooney | we have the watcher-operator reporting on changes to master opendev.org prs | |
| 14:54:30 | sean-k-mooney | we had to swap it to use c10s contianers | |
| 14:54:51 | sean-k-mooney | so its defintly possibel btu this is actully going to break because we dropped 3.9 supprot | |
| 14:55:35 | sean-k-mooney | gibi: we can chat downstream about how to prot the test change form watcher-operator to nova-operator to make this work if your interested | |
| 14:55:46 | sean-k-mooney | although maybe not this evening | |
| 14:57:04 | sean-k-mooney | the short version is https://github.com/openstack-k8s-operators/watcher-operator/blob/main/.zuul.yaml#L308-L344 defiens a c10s based job that will run on all changes ot opendev master for watcher | |
| 14:57:45 | sean-k-mooney | we have both watcher and epoxy version fo those jobs so that we will be able to do some testing on stable/2025.1 to if needed | |
| 14:57:48 | sean-k-mooney | https://github.com/openstack-k8s-operators/watcher-operator/blob/main/.zuul.yaml#L153-L270 | |
| 14:58:47 | sean-k-mooney | chandan got all that working in the last month or so, if we want to improve our upstream nova testign we can definetly do that in the future | |
| 15:00:59 | gibi | thanks for the pointers | |
| 15:16:20 | gmaan | sean-k-mooney: no PTO planned until Sept. for policy, yes that is what I will be pushing now. but I will keep eyes on stephenfin series if anything new or need re-review | |
| 15:17:54 | sean-k-mooney | gmaan: just as a follow up any removal of the tempest policy tests wont happen until 2025.1 goes to unmaintaed right | |
| 15:18:40 | sean-k-mooney | so it will be removed in 2026.2 or 2027.1 ish | |
| 15:18:59 | gmaan | sean-k-mooney: there are no specific policy tests there but idea is to move the tempest tests to move to new defaults (as default) and we have one job testing tempest on old defaults also | |
| 15:19:08 | sean-k-mooney | sorry not policy | |
| 15:19:14 | sean-k-mooney | i ment the schema validation | |
| 15:19:52 | sean-k-mooney | so updating tempest to nolonger needign to validate the repsocne once stephens seriss is supported on all stable branches | |
| 15:20:51 | sean-k-mooney | assuming 2025.2 is the first release with fully coverage we need to keep the nova schema test until 2025.1 moves to unmainted right? | |
| 15:21:02 | gmaan | ok. we can discuss that if we need to remove but anyways that can only happen after 2026.1 to unmaintained (if Nova implement all in 2025.2). But we discussed in last PTG, we might keep both side | |
| 15:21:30 | sean-k-mooney | well once we have the coverage in tree | |
| 15:21:47 | sean-k-mooney | we shoudl not need to ask people to extend the tempest schdma validation for new changes | |
| 15:22:40 | sean-k-mooney | that really what im poking at. only doing that in one place, in nova going forwarwad instead o both in nova and tempest | |
| 15:23:11 | sean-k-mooney | but your right we can discuss that at the next ptg | |
| 15:23:19 | gmaan | I am ok for that but let's discuss during 2026.1 unmaintained status change time. if no objection then I am ok to remove | |
| 15:23:36 | sean-k-mooney | well its 2025.1 not 2026.1 | |
| 15:24:07 | sean-k-mooney | anyway not todays problem :) | |
| 15:24:16 | gmaan | next PTG might be too early, anyways we need to keep them until 2026.1 (after 2025.2 EOL but I am considering 2026.1 as immediate SLURP after Nova has all schema) | |
| 15:24:43 | sean-k-mooney | right but its not when the first slurp that supprot it that is imporant | |
| 15:24:54 | sean-k-mooney | it when the last slurp that does not that matters | |
| 15:25:14 | sean-k-mooney | so its when 2025.1 goies unmaintined that tempest could consider removing the vlaidation | |
| 15:25:36 | sean-k-mooney | which will likely be during the 2026.2 or 2027.1 cycle | |
| 15:27:26 | gmaan | yeah, SLURP thing does not need to be mandatory as such. 2025.1 unmaintained is also ok | |
| 15:28:04 | gmaan | I will say let's discuss during 2026.1/2027.1 PTG when 2025.1 is moving to unmaintained | |
| 15:57:46 | stephenfin | gmaan, sean-k-mooney: Joining late, but we can/should just copy-paste the schemas from Nova to Tempest | |
| 15:58:36 | gmaan | yeah, if Nova required schema to implement during API change then it is not big deal to keep Tempest one also up to dated | |
| 16:09:32 | gmaan | as Tempest hats on, I can make sure those are syncup and tempest has all schema covered. I already started that for current schema https://review.opendev.org/q/topic:%22latest-microversion-testing%22 | |
| 16:45:29 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: Add functional reproducer for bug 2102038 https://review.opendev.org/c/openstack/nova/+/952478 | |
| 16:45:30 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: Return HTTP400 for multi spec pci alias if PCI in Placement https://review.opendev.org/c/openstack/nova/+/952479 | |
| 16:45:31 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: Multiple spec per PCI alias limitation https://review.opendev.org/c/openstack/nova/+/952480 | |
| 16:45:32 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: Validated that PCI alias has proper ids https://review.opendev.org/c/openstack/nova/+/952481 | |
| 16:45:33 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: Validate [pci]alias at service startup https://review.opendev.org/c/openstack/nova/+/952482 | |
| 16:45:35 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: Cache [pci]alias parsing https://review.opendev.org/c/openstack/nova/+/952483 | |
| 16:47:45 | JayF | TheJulia: jfyi https://review.opendev.org/c/openstack/ironic/+/949385/6 apparently needs rebasing to land. As long as it's a trivial rebase ping me and I'll reapply +2A | |
| 16:48:22 | TheJulia | heh, wrong channel :) | |
| 16:48:54 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: Add functional reproducer for bug 2102038 https://review.opendev.org/c/openstack/nova/+/952484 | |
| 16:48:55 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: Return HTTP400 for multi spec pci alias if PCI in Placement https://review.opendev.org/c/openstack/nova/+/952485 | |
| 16:48:56 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: Multiple spec per PCI alias limitation https://review.opendev.org/c/openstack/nova/+/952486 | |
| 16:48:57 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: Validated that PCI alias has proper ids https://review.opendev.org/c/openstack/nova/+/952487 | |
| 16:48:58 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: Validate [pci]alias at service startup https://review.opendev.org/c/openstack/nova/+/952488 | |
| 16:48:59 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: Cache [pci]alias parsing https://review.opendev.org/c/openstack/nova/+/952489 | |
| 16:53:21 | TheJulia | no worries | |
| 17:16:40 | sean-k-mooney | JayF: so on that | |
| 17:17:00 | sean-k-mooney | not inclduing the MTU in the metadta was specificly request by ironic a number of cycles ago | |
| 17:17:02 | JayF | I meant to tell you: welcome to the claude-code club :) It was nice to see someone not-me using it :D | |
| 17:17:21 | JayF | Sounds like we've corrected a previous mistake, then. | |
| 17:17:36 | sean-k-mooney | we do it condtionally | |
| 17:17:53 | sean-k-mooney | if the network has dhcp we dont incldue it and allow it to be managed vi dhcp | |
| 17:18:01 | JayF | Julia is the expert in this bit moreso than I am :) | |
| 17:18:07 | sean-k-mooney | btu if there is no dhcp enabled we includde it for people doing static ip | |
| 17:18:37 | sean-k-mooney | ack i was just wonderign why its only coming up now it think we didi it 2 or we release ago | |
| 17:19:45 | sean-k-mooney | TheJulia: context was includign the MTU infroamtion in teh metadat made it much harder to go form ml2/ovs to ml2/ovn becacuce that requried reducing the mtu | |
| 17:20:04 | sean-k-mooney | so neuton asked us to only set it if there was no dhcp | |
| 17:21:09 | sean-k-mooney | JayF: on claude-code ya i decied to pay for it for a year and see where the state of the art is vs local llms ectra | |
| 17:21:35 | JayF | sean-k-mooney: so, you want some advice since I've been poking at it for a few weeks? I made a openstack-dev dir, put a claude.md in it, and checked out my other projects under it | |
| 17:21:38 | sean-k-mooney | so far im likeing the terminal first approch not that i have done a lot with it | |
| 17:21:48 | TheJulia | sean-k-mooney: we've had reports of mtu weirdness and we're seeing a huge increase in not using dhcp so just makes sense to address it. | |
| 17:21:52 | JayF | the pycharm ide integration is nice, it uses the jetbrains diff stuff | |
| 17:22:07 | sean-k-mooney | JayF: you mean like this https://github.com/SeanMooney/grian-dev | |
| 17:22:12 | TheJulia | since, the mismatch between what is known and what an OS can assume otherwise introduces a huge amount of risk | |
| 17:22:13 | JayF | if you wanna use mine as a start https://www.irccloud.com/pastebin/sL4RIxrg/CLAUDE.md | |
| 17:22:29 | sean-k-mooney | JayF: i also have created https://github.com/SeanMooney/openstack-ai-style-guide | |
| 17:22:41 | sean-k-mooney | which i might rename because i want ot evolve that ot be more hten just style | |
| 17:22:51 | JayF | okay I think yours wins for quality lol | |
| 17:23:07 | JayF | but I will say: the pattern of "start claude in a dir that has all your openstack stuff checked out" has been really nice | |
| 17:23:20 | sean-k-mooney | i got claude to help write it | |
| 17:23:21 | TheJulia | plus, cases where dhcp may not even be accessible without network data out of the box and where config drive must be relied upon to get started | |
| 17:23:42 | JayF | I gave it a sample thing during trying it out, pointing it to a feature that'd require implementation in Ironic + modification of hte nova virt driver, and it did a decent job of navigating it | |
| 17:24:03 | JayF | TheJulia: sean-k-mooney: plus the uncomfortable reality that often Ironic knows more about the physical network situation than neutron/nova :( | |
| 17:24:04 | sean-k-mooney | TheJulia: so that odd becasue we do still include the mtu info if dncp is disabled on neutron | |
| 17:24:26 | sean-k-mooney | TheJulia: if we are not then that a regresion we shoudl fix in nova too | |
| 17:24:55 | TheJulia | sean-k-mooney: dhcp only matters if it is reachable out of the box, that is not always true. It is clear cut for VMs, but you can have greater hurdles with physical machines | |
| 17:25:24 | sean-k-mooney | TheJulia: ah so this is also related to prot groups and bond/vlan netowrking | |
| 17:25:33 | JayF | sean-k-mooney: everything is also related to that :) | |
| 17:25:45 | JayF | sean-k-mooney: there's very few people running ironic in the real world not using at least one of those | |