| opendevreview | Merged openstack/nova master: Handle iso+gpt detections https://review.opendev.org/c/openstack/nova/+/931833 | 00:58 |
|---|---|---|
| *** __ministry is now known as Guest5847 | 01:55 | |
| opendevreview | Tatsuya Hayashino proposed openstack/nova-specs master: Repropose instance metadata protection https://review.opendev.org/c/openstack/nova-specs/+/939190 | 01:55 |
| opendevreview | Tatsuya Hayashino proposed openstack/nova-specs master: Repropose instance metadata protection https://review.opendev.org/c/openstack/nova-specs/+/939190 | 01:59 |
| *** ryuji is now known as Guest5852 | 02:44 | |
| *** __ministry is now known as Guest5870 | 07:12 | |
| opendevreview | Merged openstack/nova-specs master: Create specs directory for 2025.2 Flamingo https://review.opendev.org/c/openstack/nova-specs/+/939091 | 08:52 |
| opendevreview | Dan Smith proposed openstack/nova master: WIP: Handle GPT image detection https://review.opendev.org/c/openstack/nova/+/933928 | 14:29 |
| opendevreview | Dan Smith proposed openstack/nova master: DNM: Test with latest oslo.utils https://review.opendev.org/c/openstack/nova/+/933444 | 14:29 |
| bauzas | #startmeeting nova | 16:01 |
| opendevmeet | Meeting started Tue Jan 14 16:01:45 2025 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| opendevmeet | The meeting name has been set to 'nova' | 16:01 |
| bauzas | heyho | 16:01 |
| fwiesel | \o | 16:01 |
| masahito | o/ | 16:02 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:02 |
| s3rj1k | hi all | 16:02 |
| elodilles | o/ | 16:03 |
| Uggla | o/ | 16:03 |
| bauzas | (on a meeting but I can run) | 16:03 |
| bauzas | #topic Bugs (stuck/critical) | 16:05 |
| bauzas | #info No Critical bug | 16:05 |
| * gibi wanders in late | 16:05 | |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:05 |
| bauzas | any bug report to discuss ? | 16:05 |
| bauzas | looks not | 16:06 |
| masahito | If there is a time, I want to talk this bug in the review priority topic. https://bugs.launchpad.net/nova/+bug/2085709 | 16:06 |
| bauzas | #topic Gate status | 16:06 |
| bauzas | masahito: sure, I'll ping you at that time | 16:07 |
| masahito | thank you. | 16:07 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:07 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:07 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | 16:07 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:08 |
| bauzas | #info Please try to provide meaningful comment when you recheck | 16:08 |
| *** __ministry is now known as Guest5909 | 16:08 | |
| opendevreview | Lajos Katona proposed openstack/nova master: blueprint: iothreads-for-instances https://review.opendev.org/c/openstack/nova/+/939254 | 16:08 |
| bauzas | periodic jobs are all green | 16:09 |
| bauzas | any gate failure to report ? | 16:10 |
| bauzas | okay moving on | 16:12 |
| bauzas | #topic Release Planning | 16:14 |
| bauzas | #link https://releases.openstack.org/epoxy/schedule.html | 16:14 |
| bauzas | #info Nova deadlines are set in the above schedule | 16:14 |
| bauzas | #info 6 weeks before Feature Freeze | 16:14 |
| bauzas | #info we'll try to create as os-traits release by the next 2 weeks, please provide your os-traits patches sooner than later. | 16:14 |
| bauzas | you know this | 16:15 |
| bauzas | #topic Review priorities | 16:16 |
| bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-status | 16:16 |
| bauzas | #action bauzas to update the etherpad with the latest changes | 16:16 |
| bauzas | masahito: you had an itemù | 16:16 |
| masahito | Thanks. | 16:16 |
| masahito | I added two bugs in the bottom of the etherpad page. | 16:17 |
| masahito | https://bugs.launchpad.net/nova/+bug/2075100 and https://bugs.launchpad.net/nova/+bug/2085709 | 16:17 |
| masahito | The second one is a bug patch I mentioned before. | 16:17 |
| gibi | masahito: I'm wondering if you problem is related to https://review.opendev.org/c/openstack/nova/+/932669 that fixed a freeze | 16:17 |
| masahito | gibi: thanks, let me check. I didn't notice the patch. | 16:18 |
| masahito | It looks like C or later release has the problem that long running thread blocks other thread operation because of libvirt connection. | 16:20 |
| bauzas | masahito: okay, that's good that you added both fixes, we'll try to review them | 16:21 |
| bauzas | can we move on ? | 16:23 |
| masahito | I'm ok, thank you. | 16:23 |
| bauzas | ack | 16:25 |
| bauzas | #topic Stable Branches | 16:25 |
| bauzas | elodilles: do you have anything ? | 16:25 |
| elodilles | #info nothing to report, stable gates seem to be healthy | 16:25 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:25 |
| elodilles | that's all from me | 16:25 |
| bauzas | cool | 16:26 |
| bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | 16:27 |
| fwiesel | No updates from my side | 16:27 |
| bauzas | fwiesel: anything on your side ? | 16:27 |
| bauzas | cool | 16:27 |
| bauzas | #topic Open discussion | 16:28 |
| bauzas | nothing on the agenda, anything else ? | 16:30 |
| masahito | If time is allowed, I want to hear your opinion for this spec, too https://review.opendev.org/c/openstack/nova-specs/+/937587 | 16:30 |
| masahito | According to the gibi's comment, it's a bug not a new feature. We're wondering the spec approval is needed or not. | 16:30 |
| bauzas | unfortunately, we're post spec approval deadline | 16:32 |
| * bauzas opens the link | 16:32 | |
| bauzas | hmmmm | 16:34 |
| masahito | yes, that's why I asked the question. If it's a bug, we can push bug fix for the problem, IIUC. But it's defined as a new feature, we'll wait the next development cycle. | 16:34 |
| bauzas | I don't have that context in mind | 16:34 |
| bauzas | sean-k-mooney: about https://review.opendev.org/c/openstack/nova-specs/+/937587/2/specs/2025.1/approved/add-mutual-prefix.rst, do you think like gibi that's just a placement bug ? | 16:34 |
| gibi | not a placement one but a nova one :) | 16:35 |
| bauzas | because that's nova which knows that, I see | 16:35 |
| bauzas | you're right | 16:35 |
| bauzas | so we should do something like set(new_traits) - set(existing_traits) to calculate the ones that should be deleted | 16:36 |
| bauzas | and if we don't do that for custom traits, I agree with you that's a bug | 16:36 |
| bauzas | because operators expect to only get custom traits that they pass | 16:37 |
| gibi | it is more like nova always generates the list of expected traits internally for the RP and then it just need to sync it with placement to overwrite what is there | 16:37 |
| gibi | I think nova never allowed outside users to add traits to RPs that is owned by nova, I expect that nova overwrites the extra traits during the periodic. | 16:38 |
| gibi | for some reason from the spec text it seem it is not the case for the traits from the provider.yaml | 16:38 |
| sean-k-mooney | reading back | 16:38 |
| gibi | so when those removed from the .yaml they are not removed from the RP | 16:38 |
| gibi | I did not looked at the code to get a better picture | 16:38 |
| sean-k-mooney | ah we dont clean them up | 16:39 |
| bauzas | yes | 16:39 |
| sean-k-mooney | i guess tha tmakes sense becuase we dont know who added them | 16:39 |
| bauzas | and the question is : is that behavior expected or not ? (to not clean them up) | 16:39 |
| masahito | yes, current behavior is one way, only adding a listed trait to the RP. | 16:39 |
| sean-k-mooney | it could be exetned to do clean up but that more a new feature then a bug | 16:39 |
| sean-k-mooney | i think we just left it out of scope | 16:40 |
| sean-k-mooney | for the inital spec | 16:40 |
| gibi | sean-k-mooney: but I expect nove to only overwrite any traits on the RP with its own list | 16:40 |
| sean-k-mooney | im not sure wha tthe best way to do that owuld be | 16:40 |
| gibi | do not try to mix and match traits from the RP and from it internal state | 16:40 |
| sean-k-mooney | well no we supprot people usign the placment api to add traits to an rp | 16:40 |
| bauzas | we have two possibilities here | 16:41 |
| sean-k-mooney | so nova cant nessiarly remove custom traits | 16:41 |
| gibi | then why we have provider.yamls? I assumed that provider.yamls was needed in the first place to make the trait addition work | 16:41 |
| sean-k-mooney | it can remove standard traits | 16:41 |
| bauzas | either we say this sounds something we need to design, and then it will be discussed for F | 16:41 |
| sean-k-mooney | no it was needed ot have a declaritive way to do that | 16:41 |
| sean-k-mooney | i think this need more discussion then we have time for in this meeting | 16:42 |
| bauzas | or we say that the expected behavior is understood and then that series is just bugfix | 16:42 |
| bauzas | if so, sounds to me a design discussion which resolves to => move to F | 16:42 |
| sean-k-mooney | my perspecitive is that CUSTOM traits cna be added/remove via the api or declaritivly, standard triaits are managed by the virt driver | 16:43 |
| sean-k-mooney | so the fact the custom trait is not removed is expected based on that view point | 16:43 |
| sean-k-mooney | however i agree we coudl recored which traits came form the provider.yaml in some form and enable nova to clean them up | 16:43 |
| sean-k-mooney | that woudl be a new functionaltiy however not a bug | 16:44 |
| sean-k-mooney | im not sold on the idea of teh mutal_prefix propsoed in the current spec | 16:45 |
| sean-k-mooney | its an approch but im not sure its the best approch | 16:46 |
| bauzas | then, as said, we're post spec freeze, this would be discussed on the Foxtrot PTG | 16:47 |
| gibi | *Flamingo | 16:47 |
| bauzas | I know | 16:47 |
| gibi | ;] | 16:47 |
| masahito | :) | 16:48 |
| bauzas | anyway, I guess we unfortunately need to move that spec to that cycle | 16:48 |
| masahito | I see the conclusion. Looks like lots of approach and design discussion are there. | 16:48 |
| bauzas | masahito: are you OK with that ? this doesn't mean we couldn't discuss that before Flamingo (meh) but we will only accept it when it's there | 16:49 |
| masahito | yup. One question is any extra discussion on the spec is also blocked by the F release PTG? | 16:50 |
| sean-k-mooney | no | 16:50 |
| sean-k-mooney | we can continue ot disucss | 16:50 |
| masahito | Got it. | 16:50 |
| sean-k-mooney | jus tmove the spec file to the correct release folder | 16:50 |
| bauzas | thanks masahito for understanding | 16:51 |
| masahito | I see there is two approach is there for the provider.yaml behavior in the meeting. We;ll update the spec including the topic. | 16:51 |
| bauzas | ++ | 16:52 |
| bauzas | okay, I guess it's time for closing the meeting | 16:53 |
| bauzas | anything anyone ? | 16:53 |
| tkajinam | I have one but I can first discuss it with a few people after the meeting is finished. | 16:53 |
| bauzas | cool | 16:54 |
| tkajinam | and bring it again to the meeting next week if needed | 16:54 |
| bauzas | ++ then, thanks all | 16:54 |
| bauzas | #endmeeting | 16:54 |
| opendevmeet | Meeting ended Tue Jan 14 16:54:44 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:54 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-14-16.01.html | 16:54 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-14-16.01.txt | 16:54 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-14-16.01.log.html | 16:54 |
| elodilles | thanks o/ | 16:55 |
| masahito | thank you. bye o/ | 16:56 |
| tkajinam | sean-k-mooney, I wonder if you think https://review.opendev.org/c/openstack/nova-specs/+/932653 can be specless or we should keep the full workflow for it. | 16:56 |
| sean-k-mooney | there are no api changes | 16:56 |
| sean-k-mooney | so it could be specless in theory | 16:57 |
| tkajinam | yeah | 16:57 |
| sean-k-mooney | i would not be opposed to that | 16:57 |
| sean-k-mooney | tkajinam: it woudl stil need a spec freeze excption either way | 16:57 |
| tkajinam | ok | 16:57 |
| sean-k-mooney | the blueprint approval dealine was also last week | 16:57 |
| tkajinam | ahh, ok | 16:58 |
| sean-k-mooney | bauzas: ^ i dont know how you feel about that | 16:58 |
| sean-k-mooney | burst qos limtis have been supproted in libvirt sin 2.4.0 baically forever | 16:58 |
| sean-k-mooney | nova just does not hook them up if they are present on a cidner volume | 16:59 |
| * bauzas looks | 16:59 | |
| tkajinam | the author asked me the way forward several times privately and I was wondering switching it to specless makes it easy to move the proposal forward | 16:59 |
| sean-k-mooney | so to me this is a small libvirt driver feature | 16:59 |
| tkajinam | yeah. what we basically need is to pick up a few additional spec keys and put these into additional iotune parameters in domain xml | 16:59 |
| sean-k-mooney | tkajinam: well the main issue is they did not respone publicly for like 2 month and we didnt get feedback form cidner | 17:00 |
| bauzas | tkajinam: would you be able to write a small description in the blueprint ? | 17:00 |
| tkajinam | sean-k-mooney, yeah. | 17:00 |
| bauzas | once we have that, then we could look whether it's specless and then accepting it as an exception if we really want | 17:00 |
| tkajinam | bauzas, yeah I can or I can ask MengyangZhang[m] to do so. | 17:00 |
| bauzas | would be nice | 17:01 |
| tkajinam | ok so I'd ask MengyangZhang[m] to add quick description and probably propose actual change, and then we can make the decision in upcoming weeks | 17:01 |
| tkajinam | based on these | 17:01 |
| bauzas | yeah, that'd be nice | 17:03 |
| bauzas | I don't want to rush them, but the sooner the better | 17:03 |
| dansmith | sean-k-mooney: melwitt: kinda surprised to see this merge with not a line of test coverage: https://review.opendev.org/c/openstack/nova/+/932669 | 17:04 |
| dansmith | especially since it looks like it's getting backported all the way | 17:04 |
| tkajinam | bauzas, yeah. we don't have very long time left for this cycle so we may need timely update to get that in for E | 17:04 |
| dansmith | especially given the backports, seems like coverage would be good no? | 17:04 |
| tkajinam | bauzas sean-k-mooney, thank you, both ! | 17:04 |
| sean-k-mooney | dansmith: i guess that a good point i was not really sure how to assert it was a proxy object | 17:04 |
| sean-k-mooney | dansmith: i wasnt sure that an issubclass check woudl work but perhasp it could | 17:05 |
| sean-k-mooney | dansmith: do you know if we have any test coverage to that effect? | 17:05 |
| dansmith | sean-k-mooney: I think this is not special in that regard | 17:05 |
| dansmith | I mean mocking the wrap method and asserting it was called would be something at least | 17:06 |
| sean-k-mooney | oh mocking _wrap_libvirt_proxy | 17:06 |
| sean-k-mooney | ya that could also work | 17:06 |
| bauzas | sean-k-mooney: we have some example https://review.opendev.org/c/openstack/nova/+/677736/5/nova/tests/unit/virt/libvirt/test_host.py | 17:06 |
| bauzas | or a Mock | 17:06 |
| bauzas | anyway, sounds to me achievable | 17:07 |
| sean-k-mooney | melwitt: ^ is that something you can do a follow up for | 17:07 |
| bauzas | not testing the threads themselves | 17:07 |
| dansmith | well, follow up won't get into the backport | 17:07 |
| sean-k-mooney | dansmith: your right that it proably shoudl have been included in the initall patch | 17:07 |
| dansmith | might be cleaner to revert and re-do it with tests... we could backport tests, but it's messy-er | 17:07 |
| sean-k-mooney | the first backport does not look like it has merged yet | 17:08 |
| sean-k-mooney | so that still an option | 17:08 |
| sean-k-mooney | i guess the refence patch that mel refers to has some examples we can reuse https://review.opendev.org/c/openstack/nova/+/677736/5/nova/tests/unit/virt/libvirt/test_host.py | 17:09 |
| dansmith | sean-k-mooney: so will you propose a revert on master? | 17:11 |
| sean-k-mooney | its kind of a wackamole probelem, it would be nice if we had some way to poison the module in test so that it could not return non wapped obejcts | 17:11 |
| sean-k-mooney | dansmith: sure i can | 17:11 |
| dansmith | thanks | 17:11 |
| dansmith | I'll stand by to fast approve :) | 17:11 |
| opendevreview | sean mooney proposed openstack/nova master: Revert "libvirt: Wrap un-proxied listDevices() and listAllDevices()" https://review.opendev.org/c/openstack/nova/+/939262 | 17:12 |
| opendevreview | sean mooney proposed openstack/nova master: Revert "libvirt: Wrap un-proxied listDevices() and listAllDevices()" https://review.opendev.org/c/openstack/nova/+/939262 | 17:12 |
| sean-k-mooney | just fixed a typo in the commit | 17:12 |
| opendevreview | ribaudr proposed openstack/os-traits master: Add 'HW_PCI_LIVE_MIGRATABLE' https://review.opendev.org/c/openstack/os-traits/+/939264 | 17:13 |
| sean-k-mooney | dansmith: thinking about it, i guess the tpool.proxy is a "contains" or "has a" relationship rahter then an inheritance so self.assertIsInstance() works in that case. so that makes sense | 17:17 |
| sean-k-mooney | we are not just replacing the metacass or simairl on teh orginl object, its fully wrapping it | 17:18 |
| melwitt | sean-k-mooney: sorry about that. I'm not sure why I thought tpool proxy stuff in general wasn't covered in unit tests. I see now that there is, so I'll add to that area with the reproposal | 19:52 |
| sean-k-mooney | melwitt: it was dansmith that noticed, i didnt think we had testign that the returned obejcts were proxies either | 19:56 |
| dansmith | maybe it's just me, but any patch that touches production code and doesn't touch anything in the test tree at all should probably be a red flag, and at least have a note in the commit message about why it's not tested | 19:57 |
| sean-k-mooney | ocationally its a pure refactor with no observable change, that how i was looking at this but that was not actully ture in this case | 19:58 |
| sean-k-mooney | we can observe that the objects are wrapped | 19:59 |
| melwitt | it was originally a test patch that I uploaded for someone to run experiments while I was debugging a downstream incident and then time passed and then for some reason I didn't find the existing test coverage. I thought it was something we don't test in general, but obviously I had missed it | 20:00 |
| dansmith | sean-k-mooney: sure a refactor is a good reason to have no test coverage showing the refactor has no impact.. but this was not that :) | 20:01 |
| *** ryuji is now known as Guest5930 | 20:02 | |
| sean-k-mooney | does anyone maintian storyboard or freezer anymore? | 20:03 |
| sean-k-mooney | i assume no | 20:03 |
| melwitt | dunno anything about freezer but afaik storyboard is no longer being developed | 20:07 |
| sean-k-mooney | so there is an eventlet isseu with watcher im trying to debug | 20:08 |
| sean-k-mooney | but very few projects use the apschduler lib | 20:08 |
| JayF | sean-k-mooney: obligatory: have you ensured the new eventlet+oslo.log releases don't fix it? | 20:08 |
| sean-k-mooney | and sofar i dont think they use eventlet | 20:08 |
| sean-k-mooney | JayF: yep | 20:09 |
| JayF | too bad :( | 20:09 |
| sean-k-mooney | im tryign to confirm if wathcer is the only project that uses that lib and eventlet | 20:09 |
| sean-k-mooney | zuul ueses apscheduler for example but i dotn thinik it uses eventlet | 20:10 |
| sean-k-mooney | oh also the issue only happen on python 3.12 and the actual issue is happenign isn sqlachemy... | 20:10 |
| sean-k-mooney | so you know tottally trivial to figure out what the hell is happening | 20:11 |
| melwitt | good times | 20:12 |
| sean-k-mooney | the fun part is they are working on a 4.0 release like sqlalchme 2.0 and have been in the process of that migration for a while | 20:19 |
| sean-k-mooney | so even if i get this workign with 3.11 we weill have to eventually port to the new 4.0 interface, 3.x is still supproted at least | 20:20 |
| sean-k-mooney | the 4.x brnach supprot sqlalchemy 2.0 im not sure that is true of the 3.x branch but that one of the paths im looking into | 20:23 |
| opendevreview | Douglas Viroel proposed openstack/nova master: WIP - Add support for showing scheduler_hints in server details https://review.opendev.org/c/openstack/nova/+/938604 | 20:35 |
| opendevreview | Douglas Viroel proposed openstack/nova master: Add support for showing scheduler_hints in server details https://review.opendev.org/c/openstack/nova/+/938604 | 20:36 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!