| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-07 | |||
| 14:49:49 | dvo-plv | rewrite spec file | |
| 14:50:11 | dvo-plv | or we can move with it and not limit us with bobcat | |
| 14:51:23 | bauzas | sure, but we'll keep forever some trait support for something we don't need in the very next future, ie. D :) | |
| 14:51:49 | bauzas | this is the exact reason why we do specifications, in order to avoid such confusions | |
| 14:52:22 | bauzas | and again, I don't get how antelope computes will magically decorate them with a trait, given the code isn't there | |
| 14:52:47 | dvo-plv | when user starts to update the system | |
| 14:53:02 | bauzas | dvo-plv: let me explain you | |
| 14:53:26 | dvo-plv | he could have situation when one compute old, another has altests release and vm was run on the latest and to avoid issue with qemu we could filter it with trait | |
| 14:53:48 | bauzas | dvo-plv: in https://review.opendev.org/c/openstack/nova/+/876075/25/nova/virt/libvirt/driver.py#9046 | |
| 14:53:54 | bauzas | you're adding a trait | |
| 14:54:27 | bauzas | and in the conditional below, you're decorating the compute with that trait | |
| 14:55:03 | bauzas | so, indeed, Caracal computes will be decorated with that trait (since libvirt min is enough), I don't disagre | |
| 14:55:05 | bauzas | disagree* | |
| 14:55:19 | bauzas | now, Bobcat computes won't cointain that code, rightN | |
| 14:55:26 | bauzas | and Antelope ones, too, right? | |
| 14:55:55 | dvo-plv | yes | |
| 14:58:06 | bauzas | for Bobcat, this isn't a problem : since the min is recent enough, you're good | |
| 14:58:30 | bauzas | for Antelope, indeed, depending on the OS version, you may or may not have the right libvirt version | |
| 15:00:09 | bauzas | but unfortunately Antelope computes can't decorate themselves with https://review.opendev.org/c/openstack/nova/+/876075/25/nova/virt/libvirt/driver.py since they don't have that code running | |
| 15:01:11 | dvo-plv | yes and in case if Antelope will have old qemu, it will help to avoid wrong qemu command | |
| 15:02:41 | bauzas | dvo-plv: so again, why do we need to use a trait if we just say "we will only send that instance to Bobcat and newer computes" ? | |
| 15:05:06 | bauzas | we could also do something in the API like https://github.com/openstack/nova/blob/b64ecb0cc776bd3eced674b0f879bb23c8a4b486/nova/compute/api.py#L284-L312 | |
| 15:05:35 | bauzas | and return some HTTP40x exception if not all the computes are Bobcat or newer | |
| 15:07:52 | dvo-plv | So, you suggest to remove trait and add somewhere in the scheduler check that if packed ring was requested and release of the target node is equal or higher then Bobcat we approve live migration to this to this node ? | |
| 15:11:54 | bauzas | dvo-plv: that's a good question, we should either restrict the placement query to >=Bobcat computes (but I don't know if we have a construct like this) or we could just have some API check that would ensure that all computes are above or equal Bobcat version, like the link I passed to you | |
| 15:12:49 | dvo-plv | I see your point and it sounds correctly | |
| 15:13:16 | bauzas | dvo-plv: I'm not telling you to drop the libvirt additions you made in https://review.opendev.org/c/openstack/nova/+/876075 | |
| 15:13:42 | bauzas | and nothing changes on the UX side (image property or flavor extraspec) | |
| 15:14:04 | bauzas | that's just the scheduling part | |
| 15:15:02 | bauzas | and we could even lift that restriction in the API once we arrive in D timeframe, since we'll only support N-1 upgrade | |
| 15:15:13 | dvo-plv | But maybe we could also invite sean-k-mooney and gibi who also take a part in the spec file design to make one more common decision in that topic to choose new vector which i have to investigate how and where to implement it | |
| 15:15:23 | bauzas | sure | |
| 15:15:58 | bauzas | dvo-plv: just my guess, was that spec originally proposed in Antelope ? | |
| 15:16:30 | bauzas | if so, the libvirt check would sound more important to me by that time | |
| 15:16:51 | bauzas | but the fact is, we bumped our mins in Bobcat, so that simplifies the logic :) | |
| 15:17:42 | dvo-plv | i'm not familiar with release date, I thought that it was before Zed release May 03 2023 https://review.opendev.org/c/openstack/nova-specs/+/868377 | |
| 15:18:56 | bauzas | I need to disappear for 20 mins, but I can read | |
| 15:28:14 | opendevreview | Dmitriy Rabotyagov proposed openstack/nova stable/2023.1: add a regression test for all compute RPCAPI 6.x pinnings for rebuild https://review.opendev.org/c/openstack/nova/+/900306 | |
| 15:28:31 | opendevreview | Dmitriy Rabotyagov proposed openstack/nova stable/zed: add a regression test for all compute RPCAPI 6.x pinnings for rebuild https://review.opendev.org/c/openstack/nova/+/900307 | |
| 15:29:27 | dvo-plv | sean-k-mooney, gibi | |
| 15:29:30 | dvo-plv | So, in a conclusion we have two open questions. How we need to proceed with scheduling, trait or release filter | |
| 15:29:46 | dvo-plv | Does tempest test is a required from us ? | |
| 15:47:35 | bauzas | noonedeadpunk: thanks for proposing the backparts, hadn't time yet | |
| 15:47:50 | bauzas | reminder: nova meeting in 13 mins here. | |
| 15:47:58 | noonedeadpunk | no worries. I will push rest on top in couple of mins | |
| 15:48:27 | bauzas | dvo-plv: I'm not saying a tempest test is mandatory, just a preference | |
| 15:48:34 | bauzas | that said, at least a functional test seems needed | |
| 16:02:09 | bauzas | shit, forgot the meeting was in another impromptu call :( | |
| 16:02:11 | bauzas | #startmeeting | |
| 16:02:11 | opendevmeet | bauzas: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' | |
| 16:02:11 | elodilles | o/ | |
| 16:02:15 | bauzas | #startmeeting nova | |
| 16:02:15 | opendevmeet | Meeting started Tue Nov 7 16:02:15 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:02:15 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:02:15 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:02:22 | elodilles | o/ | |
| 16:02:30 | bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 16:02:45 | bauzas | (this will be live, I haven't updated the wiki yet) | |
| 16:03:08 | dansmith | o/ | |
| 16:03:43 | gibi | o/ | |
| 16:04:44 | bauzas | there, let's start | |
| 16:04:48 | bauzas | #topic Bugs (stuck/critical) | |
| 16:04:53 | bauzas | #info No Critical bug | |
| 16:04:58 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 32 new untriaged bugs (-4 since the last meeting) | |
| 16:05:02 | 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:12 | bauzas | Uggla_: any bug you wanted to tell us ? | |
| 16:05:52 | bauzas | anyway, let's move on | |
| 16:06:09 | bauzas | elodilles: fancy taking the baton ? | |
| 16:06:44 | elodilles | bauzas: yepp | |
| 16:06:54 | elodilles | i can take it :) | |
| 16:06:55 | bauzas | cool thanks | |
| 16:07:08 | bauzas | #info bug baton is elodilles | |
| 16:07:15 | bauzas | elodilles: ++ | |
| 16:08:12 | Uggla_ | oh | |
| 16:08:16 | Uggla_ | yes | |
| 16:08:23 | bauzas | #topic Gate status | |
| 16:08:28 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:08:33 | bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | |
| 16:08:43 | Uggla_ | https://bugs.launchpad.net/nova/+bug/2039381 | |
| 16:08:47 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:09:13 | bauzas | Uggla_: oh sorry we moved to the gate section, can we discuss your bug in the open discussion then ? | |
| 16:09:46 | dansmith | melwitt has a fix up for the vnc ting.. I've asked her a question, but assume we'll get that on the way soon once she's around | |
| 16:09:58 | bauzas | fwiw, all periodics are in green | |
| 16:10:04 | Uggla_ | yep sure | |
| 16:10:08 | bauzas | dansmith: oh, nice to hear, any change I could dent ? | |
| 16:10:41 | dansmith | sec | |
| 16:11:17 | dansmith | https://review.opendev.org/c/openstack/grenade/+/900257 | |
| 16:11:50 | bauzas | dansmith: cool, CCing it | |
| 16:12:18 | bauzas | oh that's why it's failing intermittently | |
| 16:12:25 | bauzas | depending on the host you land | |
| 16:12:53 | bauzas | I nacked the idea when gibi suggested it because I was too lazy to look at the job and I just trusted the fact we got green runs | |
| 16:12:56 | bauzas | what a shame | |
| 16:13:04 | dansmith | bauzas: that's what I'm wondering | |
| 16:13:19 | dansmith | seems like we should be failing a lot more though, | |
| 16:13:34 | dansmith | and why this has become a thing all of a sudden also seems weird if it's been broken like this for a while | |
| 16:13:43 | dansmith | but otherwise yeah, hopefully an easy fix | |
| 16:13:56 | bauzas | because yesterday we merged my patch that added the servers actions checks in grenade | |
| 16:14:18 | bauzas | this test was flakey but never run, and I just opened the can of worms | |
| 16:14:33 | dansmith | but I think it has failed on other patches, not just yours | |
| 16:15:03 | bauzas | well, then the vnc check itself could be present on other tempest tests | |