| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-07 | |||
| 14:28:45 | dvo-plv | no, this feature is relayted to the nova | |
| 14:28:46 | bauzas | I'm actually confused | |
| 14:29:04 | bauzas | nova will pick the computes that are recent enough, gotcha | |
| 14:29:10 | bauzas | but | |
| 14:29:21 | dvo-plv | its about acceleration for qemu | |
| 14:30:04 | bauzas | oh I see | |
| 14:30:16 | bauzas | so we're just exposing the feature as a trait | |
| 14:30:24 | dvo-plv | yes | |
| 14:30:51 | bauzas | okay, then nevermind my comment on dependencies, but there are still some things to write about testing :) | |
| 14:31:01 | bauzas | I'll update | |
| 14:32:51 | bauzas | dvo-plv: I may propose an alternative, I'm not particarly fond of adding another trait for something only QEMU | |
| 14:33:05 | bauzas | we already add a lot of those | |
| 14:34:29 | dvo-plv | Maybe we should leave as is. We already did alot of work here and testing for implement this | |
| 14:40:16 | bauzas | dvo-plv: I still don't get why we need a trait, that's the point | |
| 14:40:26 | bauzas | https://docs.openstack.org/nova/latest/reference/libvirt-distro-support-matrix.html#min-libvirt-qemu-version-and-next-min-libvirt-qemu-version-table | |
| 14:40:46 | bauzas | it says here that Antelope libvirt min is 6.0 | |
| 14:40:50 | bauzas | and Bobcat 7.0 | |
| 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 | elodilles | o/ | |
| 16:02:11 | opendevmeet | bauzas: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' | |
| 16:02:11 | bauzas | #startmeeting | |
| 16:02:15 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:02:15 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 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 | bauzas | #startmeeting 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 ? | |