Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-11-07
10:47:46 dvo-plv Sure, I will udpate all what i can, another discuss later
10:49:16 bauzas dvo-plv: ack, I'll ping you this afternoon so
10:49:44 opendevreview Danylo Vodopianov proposed openstack/nova-specs master: Re-propose using VirtIO PackedRing Configuration support for 2024.1 https://review.opendev.org/c/openstack/nova-specs/+/895924
12:18:02 opendevreview Stephen Finucane proposed openstack/nova master: docs: Add documentation on server groups https://review.opendev.org/c/openstack/nova/+/899979
14:06:15 opendevreview Dmitriy Rabotyagov proposed openstack/nova-specs master: [spec] Add Cross-AZ scheduling blueprint https://review.opendev.org/c/openstack/nova-specs/+/900296
14:12:40 opendevreview Dmitriy Rabotyagov proposed openstack/nova-specs master: [spec] Add Cross-AZ scheduling blueprint https://review.opendev.org/c/openstack/nova-specs/+/900296
14:13:12 noonedeadpunk I guess I'm a bit late for the spec review day, sorry :(
14:13:36 noonedeadpunk had some off time during previous week so wasn't able to work on it then
14:20:20 bauzas noonedeadpunk: no worries, we plan to do a second round of specs in a next review day
14:20:38 bauzas like mine I didn't had time to write yet :)
14:24:49 dvo-plv bauzas, Hello, I get your latest comments
14:25:38 dvo-plv https://review.opendev.org/c/openstack/nova-specs/+/895924/6/specs/2024.1/approved/virtio_packedring_configuration_support.rst#154 Those patches which you mentioned are from another our blueprint
14:25:52 dvo-plv I believe that patches are group by topic
14:26:24 dvo-plv Should I add links on all patches to the spec file ?
14:26:49 bauzas dvo-plv: hey
14:27:40 bauzas dvo-plv: I don't particularly want to track the implementation patches in a spec, I'd rather prefer if you can write something in the spec saying that the nova changes depend on neutron and os-vif changes that are on the fly
14:27:59 opendevreview John Garbutt proposed openstack/nova-specs master: WIP: Add spec for PCI Groups https://review.opendev.org/c/openstack/nova-specs/+/899719
14:28:05 dvo-plv I see, okay I will do it
14:28:08 bauzas I see https://review.opendev.org/q/topic:bp%252Fvirtio-packedring-configuration-support
14:28:26 bauzas does that mean anything is required on the neutron side ?
14:28:35 bauzas nothing*
14:28:41 bauzas dvo-plv: ^
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

Earlier   Later