| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-25 | |||
| 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 | |
| 09:58:09 | sean-k-mooney | and it also increase memory usagein the guest | |
| 09:58:15 | sean-k-mooney | so it can break things | |
| 09:58:40 | stephenfin | So not quite a free lunch. Pity. It would be good to note that in the spec | |
| 09:59:12 | sean-k-mooney | stephenfin: to be clear our virt team told us not to bother enableing it because of the perfroamce impact of the intel viommu for sriov | |
| 09:59:41 | stephenfin | TIL. Yeah, definitely one to note on the spec | |
| 10:00:06 | stephenfin | Last one, do we actually want an extra spec for this? We don't traditionally do extra specs for hardware stuff | |
| 10:01:09 | sean-k-mooney | right normlaly it hsould be image only | |
| 10:01:34 | sean-k-mooney | we have broken that a few times now with the vtpm and vpmu extra specs | |
| 10:01:44 | sean-k-mooney | so at this point im kind of ok with it | |
| 10:02:04 | sean-k-mooney | if the guest does not have the driver the iommu will just not get used by the kernel in the guest i belive | |
| 10:02:19 | sean-k-mooney | but i have not tested that | |
| 10:04:10 | opendevreview | Balazs Gibizer proposed openstack/nova master: Accept both 1 and Y as AMD SEV KVM kernel param value https://review.opendev.org/c/openstack/nova/+/843254 | |
| 10:04:36 | gibi | sean-k-mooney: this is a fix for what James saw the other day downstream ^^ | |
| 10:09:59 | sean-k-mooney | ah nice | |
| 10:11:38 | sean-k-mooney | gibi: can we not use the oslo stringutils str to bool function | |
| 10:11:49 | sean-k-mooney | i think that woudl be better | |
| 10:13:19 | gibi | sure, why not | |
| 10:13:21 | sean-k-mooney | bool_from_string | |
| 10:13:40 | sean-k-mooney | basiclaly whhen it becomes YES or true | |
| 10:13:46 | sean-k-mooney | i dont want to have to fix it again | |
| 10:16:39 | gibi | good point | |
| 10:16:44 | gibi | I will respin in a sec | |
| 10:18:00 | opendevreview | Balazs Gibizer proposed openstack/nova master: Accept both 1 and Y as AMD SEV KVM kernel param value https://review.opendev.org/c/openstack/nova/+/843254 | |