| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-07 | |||
| 14:41:25 | bauzas | so basically, the problem we need to solve is only with Antelope computes or I'm stupid | |
| 14:42:01 | dvo-plv | For scheduling process, when operator makes OpenStack updates | |
| 14:42:33 | bauzas | yeah, I got it, but look at that table | |
| 14:42:38 | dvo-plv | it case the live migration when one node works with packed ring and another not | |
| 14:42:55 | dvo-plv | when user make update of the system | |
| 14:43:18 | bauzas | sure, but Bobcat (and Caracal) require libvirt 7.0 as min | |
| 14:43:39 | bauzas | so you're guaranteed that libvirt is newer than 6.7, which is what you want | |
| 14:44:37 | bauzas | the only case we need to solve is a very particular case, which is when the operator has a rolling upgrade environment on a SLURP cadence, ie. Caracal controllers and computes + a certain number of Antelope computes | |
| 14:44:54 | bauzas | in that specific case, we don't wanna land on an Antelope compute, for sure | |
| 14:45:22 | dvo-plv | but when user hsa antelope and do system update, he could faced with the situation when one compute has antelope with old qemu and other already bobcat. to prevent wrong migration we will filter nodes with trait | |
| 14:45:28 | bauzas | this is why I'm proposing to add a prefilter that would only check the compute version | |
| 14:45:58 | bauzas | how would you do that for antelope computes since you can't backport that detection code ? | |
| 14:46:50 | bauzas | what I'm suggesting is to ask this feature to be Bobcat min | |
| 14:47:35 | bauzas | I know I approved https://review.opendev.org/c/openstack/os-traits/+/876069 but I wasn't understand this was just for decorating a libvirt version | |
| 14:49:35 | dvo-plv | it will required to delete it from the os-traits, rewrite nova code https://review.opendev.org/c/openstack/nova/+/876075 and glance | |
| 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 ? | |