| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-06 | |||
| 22:16:52 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: Support to pass PFs in device_addresses https://review.opendev.org/c/openstack/nova/+/900251 | |
| 22:35:26 | opendevreview | Steven Relf proposed openstack/nova master: Adding basic auth to dynamic vendordata api calls https://review.opendev.org/c/openstack/nova/+/900252 | |
| #openstack-nova - 2023-11-07 | |||
| 07:50:16 | bauzas | happy spec review day, everyone :) | |
| 09:21:56 | gibi | I did my first pass on the spec. I skipped re-proposes as those probably doesn't need much discussion anyhow | |
| 09:22:06 | gibi | s/spec/specs/ | |
| 09:28:35 | bauzas | gibi: I still need to do my duty, still working on f... vgpus | |
| 09:35:51 | opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Add migration_inbound_addr https://review.opendev.org/c/openstack/nova/+/900203 | |
| 09:38:07 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: test hostname based migration URL https://review.opendev.org/c/openstack/nova/+/900275 | |
| 09:42:37 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: Support to pass PFs in device_addresses https://review.opendev.org/c/openstack/nova/+/900251 | |
| 09:42:43 | bauzas | there we go, I'm done | |
| 09:43:02 | bauzas | I'll just await sean-k-mooney and dansmith for discussing about that | |
| 10:46:39 | dvo-plv | bauzas, Hello. I'm currently resolving your comments in the spec file. I have a question regarding dependencies | |
| 10:47:01 | bauzas | dvo-plv: I need to go off in a few mins | |
| 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 ? | |