| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-06 | |||
| 14:15:51 | bauzas | dvo-plv: sorry I'm currently doing a lot of things, but we plan to do a spec review day on tomorrow | |
| 14:16:45 | dvo-plv | Sure, thanks | |
| 14:33:13 | bauzas | dansmith: I know sean-k-mooney is on PTO, but the more I think, the less I like to create a specific config option for SR-IOV GPUs | |
| 14:34:31 | dansmith | bauzas: I didn't follow the rest of your conversation after our gmeet | |
| 14:35:11 | dansmith | are you talking about the max_devices one or what? | |
| 14:35:14 | bauzas | so I think I'll just create a new change for telling that we would support a new wilcard "*" for device_addresses which would be the default | |
| 14:35:18 | bauzas | dansmith: yeah | |
| 14:35:44 | dansmith | okay I'm not sure how that solves the prioblem | |
| 14:35:48 | bauzas | dansmith: I tried to see how we could use max_instances (or max_devices) for both SR-IOV and non-SRIOV GPUs, but it would be dififcult | |
| 14:36:08 | bauzas | so if max_instances would be only for SRIOV GPUs, it would be sadf | |
| 14:36:22 | dansmith | I thought the non-SRIOV ones didn't need it, and that's why the default would be None or -1 to not apply that to those | |
| 14:36:27 | dansmith | why? | |
| 14:36:37 | dansmith | it's very specifically only needed for those, IIRC | |
| 14:38:11 | bauzas | we have two different behaviours | |
| 14:38:25 | bauzas | either we ask for SRIOV operators to provide all the VFs they want, | |
| 14:38:46 | bauzas | or we try them to provide a specific option | |
| 14:41:39 | bauzas | anyway, let me try to provide a specific change and we'll see | |
| 14:42:20 | dansmith | mkay | |
| 15:10:36 | opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Add migration_inbound_addr https://review.opendev.org/c/openstack/nova/+/900203 | |
| 15:11:28 | gibi | bauzas, sean-k-mooney: ^^ it belongs to https://blueprints.launchpad.net/nova/+spec/libvirt-migrate-with-hostname-instead-of-ip which I will bring up for approval on the tomorrows meeting | |
| 15:13:19 | bauzas | okay, but too many things I work on | |
| 15:13:31 | bauzas | f nivia | |
| 15:17:43 | gibi | this is just a fyi, we will discuss it further tomorrow on the meeting | |
| 16:10:21 | opendevreview | Merged openstack/nova master: Adding server actions tests to grenade-multinode https://review.opendev.org/c/openstack/nova/+/899375 | |
| 16:13:31 | bauzas | \o/ | |
| 17:32:50 | auniyal6 | bauzas can this be merged https://review.opendev.org/c/openstack/nova/+/865336, it was created by gibi then sean backported it till wallaby | |
| 17:33:28 | auniyal6 | this whole topic only wallaby this pending https://review.opendev.org/q/topic:bug%252F1970467 | |
| 17:33:53 | auniyal6 | this will be helpful for other backports | |
| 17:36:30 | bauzas | sorry, can't do it, other priorities for the moment due to f... nvidia issues | |
| 17:37:08 | auniyal6 | ack | |
| 17:39:51 | dansmith | that seems like a pretty impactful backport to me, just skimming | |
| 17:40:09 | dansmith | I'd like to chat with sean about it tomorrow when he's back before I review/approve | |
| 17:40:23 | auniyal6 | thanks dansmith | |
| 17:40:50 | bauzas | my head is just about to explode | |
| 17:41:09 | bauzas | too many things on the pile, that's it | |
| 18:41:06 | opendevreview | Amit Uniyal proposed openstack/nova stable/yoga: Fix the PCI device capability dict creation https://review.opendev.org/c/openstack/nova/+/899252 | |
| 18:41:07 | opendevreview | Amit Uniyal proposed openstack/nova stable/yoga: Store pf_mac_address and vf_num in extra_info https://review.opendev.org/c/openstack/nova/+/899253 | |
| 18:41:08 | opendevreview | Amit Uniyal proposed openstack/nova stable/yoga: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/899254 | |
| 20:15:39 | opendevreview | Pierre Riteau proposed openstack/nova master: Remove outdated comment about allocation ratios https://review.opendev.org/c/openstack/nova/+/900242 | |
| 22:16:51 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: add max_instances and a wildcard https://review.opendev.org/c/openstack/nova/+/900250 | |
| 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 | |