| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-24 | |||
| 20:10:52 | opendevreview | Artom Lifshitz proposed openstack/nova stable/wallaby: DNM: Testing live migration with local attach https://review.opendev.org/c/openstack/nova/+/843146 | |
| 21:32:02 | opendevreview | Artom Lifshitz proposed openstack/nova stable/wallaby: DNM: Testing live migration with local attach https://review.opendev.org/c/openstack/nova/+/843146 | |
| 23:21:42 | opendevreview | Ghanshyam proposed openstack/nova stable/ussuri: DNM: Testing stable/ussuri with tempest fix for constraints mismatch https://review.opendev.org/c/openstack/nova/+/843046 | |
| 23:37:18 | opendevreview | Miguel Lavalle proposed openstack/os-vif master: Delete trunk bridges to avoid race with Neutron https://review.opendev.org/c/openstack/os-vif/+/841499 | |
| #openstack-nova - 2022-05-25 | |||
| 03:25:13 | opendevreview | Andrew Bogott proposed openstack/nova master: libvirt: add the purge_rbd_snaps_on_delete config option https://review.opendev.org/c/openstack/nova/+/843228 | |
| 03:35:05 | opendevreview | Andrew Bogott proposed openstack/nova master: libvirt: add the purge_rbd_snaps_on_delete config option https://review.opendev.org/c/openstack/nova/+/843228 | |
| 04:55:18 | opendevreview | Merged openstack/nova master: libvirt: Add a workaround to skip compareCPU() on destination https://review.opendev.org/c/openstack/nova/+/838926 | |
| 09:01:23 | gibi | stephenfin: when you are around, can we discuss the config option open questions in https://review.opendev.org/c/openstack/nova-specs/+/791047 ? | |
| 09:09:56 | stephenfin | gibi: Sure, on the review? | |
| 09:10:27 | gibi | we can talk here :) | |
| 09:10:33 | gibi | that is probably quicker | |
| 09:10:41 | gibi | so my first question is | |
| 09:11:03 | gibi | what is the reason behind you suggest no to rename the whitelist but add a totally new conf option? | |
| 09:12:36 | stephenfin | Oh, I thought that was what you were proposing at the beginning | |
| 09:12:40 | stephenfin | ...of the spec | |
| 09:13:58 | stephenfin | "The ``[pci]passthrough_whitelist`` config option will be deprecated for eventual removal and replaced with the new ``[pci]device_list`` config option."! | |
| 09:14:02 | stephenfin | ^ that threw me | |
| 09:14:10 | gibi | OK so we want to deprecate the old name | |
| 09:14:21 | gibi | but keep the same config opt definition | |
| 09:14:31 | gibi | (+ extend it with resource_class and traits) | |
| 09:15:11 | stephenfin | Okay, gotcha. I misunderstood. Please ignore that comment so | |
| 09:15:15 | gibi | cool | |
| 09:15:24 | gibi | the other is about the naming of the new option | |
| 09:15:37 | gibi | If I understand correctly you would like a singular name | |
| 09:15:59 | gibi | but probably neither singular nor plural is fully correct | |
| 09:16:16 | gibi | as a single entry in the device_list can match to zero, one, or multiple devices | |
| 09:16:51 | gibi | OR we could try to name the option not from the matched device(s) perspective but from the filtering / matching perspective | |
| 09:17:09 | gibi | i.e. device_spec device_filter | |
| 09:17:46 | stephenfin | Yeah, I forgot that it would accept a list. That's a really awful option | |
| 09:18:00 | stephenfin | device_spec or device_filter both wfm | |
| 09:18:21 | stephenfin | so long as it's not device_list really :) | |
| 09:18:48 | gibi | sean-k-mooney[m]: ^^ how do you feel about naming the device_list to [pci]device_spec or [pci]device_filter ? | |
| 09:19:17 | gibi | stephenfin: thanks. | |
| 09:31:14 | sean-k-mooney1 | i think device_filter was what i used in an older version | |
| 09:31:26 | sean-k-mooney1 | so im ok with either device_spec or device_filter | |
| 09:33:09 | gibi | cool | |
| 09:34:39 | gibi | sean-k-mooney1, bauzas: the last thing is the CUSTOM_ prefix. I will keep the normalization and prefixing in the spec as is and we can re-discuss that during code / doc review if needed. | |
| 09:35:31 | sean-k-mooney | gibi: ya im ok to defer that to the code review since bauzas's main ask was to document it properly | |
| 09:39:01 | gibi | yepp, and also bauzas is on PTO for the rest of the week :) | |
| 09:39:50 | gibi | I will update the config naming in the spec today | |
| 09:40:01 | gibi | and then I will ask you and stephenfin to approve it:) | |
| 09:42:10 | sean-k-mooney | ack :) | |
| 09:42:31 | sean-k-mooney | one question | |
| 09:42:43 | sean-k-mooney | do we want to add the json list support to the alas | |
| 09:42:55 | sean-k-mooney | to have partity with the device_filter | |
| 09:44:17 | sean-k-mooney | i personally woudl really like to not have to deal with the multiopt syntax but you dont have to fix that its just on my wishlist for some day | |
| 09:44:47 | gibi | I think it is a better direction to get rid of the multiopt | |
| 09:45:03 | gibi | but that is definitely something that is not in scope now | |
| 09:46:04 | sean-k-mooney | right so not suggesting geting rid of the multiopt just allowing alias=[{...},{...}] | |
| 09:46:20 | sean-k-mooney | but ok i can propose that as a specless blueprint some time | |
| 09:47:15 | gibi | OK, I think the list part can be a separate small thing | |
| 09:48:40 | stephenfin | If we got rid of MultiStrOpt, IMO we should look at what we did for the NUMA network affinity spec, where we dynamically generated configuration sections/options and flattened the list | |
| 09:49:11 | sean-k-mooney | stephenfin: no i dont really like that either | |
| 09:49:24 | sean-k-mooney | we could | |
| 09:49:34 | sean-k-mooney | but it woudl be non trivial to do | |
| 09:49:53 | sean-k-mooney | we dont have a name for thses to key off | |
| 09:50:16 | sean-k-mooney | they are already json strings | |
| 09:50:18 | gibi | didn't we had some race condition issues with dynamic opts? | |
| 09:50:26 | stephenfin | [pci] device_specs = foo, bar | |
| 09:50:31 | sean-k-mooney | just supproting json lists simes simpel | |
| 09:50:31 | stephenfin | [device_spec_foo] vendor_id = ffff product_id = ffff | |
| 09:50:44 | sean-k-mooney | stephenfin: right we dont have the foo and bar names today | |
| 09:50:55 | stephenfin | ah yeah, you'd invent them | |
| 09:50:56 | sean-k-mooney | we would have to just add them for the sake fo the option | |
| 09:51:04 | sean-k-mooney | for the alias that totally works | |
| 09:51:10 | stephenfin | Just arbitrary identifiers. Very easy to script | |
| 09:51:18 | stephenfin | Anyway, nothing to do with this spec | |
| 09:51:26 | sean-k-mooney | you know it will end up being 001 002 003] | |
| 09:51:28 | sean-k-mooney | #but ya | |
| 09:51:46 | stephenfin | changing the topic, why does the vIOMMU model have to be configurable? | |
| 09:51:58 | stephenfin | other than MOAR PWR!!!?! | |
| 09:52:01 | stephenfin | :) | |
| 09:52:05 | sean-k-mooney | its simpler then dealing with having to doublel escape them in the local.conf for sure | |
| 09:52:25 | sean-k-mooney | stephenfin: because i think it changes the kernel driver in the guest | |
| 09:52:49 | sean-k-mooney | the same way virtio vs e1000 does for nics or cirrus vs qxl for video_model | |
| 09:53:30 | sean-k-mooney | if it was next year i would porbaly have said just use virtio and be done with it | |
| 09:53:34 | stephenfin | and we're thinking someone would want to use != virtio nowadays | |
| 09:53:36 | stephenfin | ? | |
| 09:53:48 | sean-k-mooney | well no distro i know of ships with virtio suppoprt | |
| 09:53:59 | stephenfin | as in libvirt version? | |
| 09:54:06 | sean-k-mooney | as in qemu version but ya | |
| 09:54:21 | sean-k-mooney | i would have to check 22.04 and rhel 9 | |
| 09:54:32 | sean-k-mooney | but that is very new | |
| 09:54:57 | stephenfin | libvirt *and* qemu version | |
| 09:55:10 | sean-k-mooney | libvirt 8.3.0 | |
| 09:55:17 | sean-k-mooney | not sure about the qemu version | |
| 09:55:17 | stephenfin | pity :( | |
| 09:55:55 | sean-k-mooney | initally i was also just hoping for hw:viommu=True|False | |
| 09:55:55 | stephenfin | would it be crazy to at least set a sane default (i.e. virtio if libvirt >= 8.3.0)? | |
| 09:56:03 | stephenfin | yeah, me too | |
| 09:56:31 | sean-k-mooney | if you want we coudl add hw:viommue=True|False and have it set it automatically | |
| 09:56:34 | stephenfin | also, do we want an extra spec for this. We don't traditionally do extra specs for hardware stuff | |
| 09:56:44 | sean-k-mooney | but we likely need a way to override | |
| 09:56:49 | stephenfin | I'd rather 'hw:viommu_model=auto' | |
| 09:57:03 | sean-k-mooney | im fine with that | |
| 09:57:05 | stephenfin | if we go that route and we are not turning on vIOMMU by default | |
| 09:57:15 | stephenfin | (why are we not doing that too btw?) | |
| 09:57:24 | sean-k-mooney | well ya i dont think we shoudl trun it on by default | |
| 09:57:38 | sean-k-mooney | turning it on by defaul? | |
| 09:57:57 | sean-k-mooney | i think it has negitive performance impact if you are using pci passthough | |