| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-07 | |||
| 08:59:00 | bauzas | sorry, can't really help more :( | |
| 08:59:23 | bauzas | I'm not working at all with nvidia, I'm just a redhat engineer asked to deliver some partner features ;) | |
| 09:01:02 | bauzas | swp20: saying nothing confidential here, but I know there is some opensource driver aimed to be available for testing mdev live migration at the kernel level | |
| 09:01:20 | bauzas | of course, this won't be related to v100 | |
| 09:01:30 | bauzas | but that's a way for testing | |
| 09:01:41 | bauzas | the other option is the mtty modules | |
| 09:02:02 | bauzas | the last one is using gvt-g hardware | |
| 09:02:20 | bauzas | but those are only desktoip i920 cards | |
| 09:03:32 | swp20 | bauzas: ack, thanks any way. | |
| 09:58:41 | opendevreview | fionali proposed openstack/nova master: manager: Reduce unnecessary calls https://review.opendev.org/c/openstack/nova/+/795027 | |
| 10:07:43 | opendevreview | Lee Yarwood proposed openstack/nova master: libvirt: fup docs and typing for _hard_reboot flow https://review.opendev.org/c/openstack/nova/+/795081 | |
| 10:45:33 | elodilles | lyarwood bauzas : could you review melwitt's patch to unblock stable gate? https://review.opendev.org/q/I02b2b851a74f24816d2f782a66d94de81ee527b0 | |
| 10:46:57 | elodilles | I mean... this is the 1st one: https://review.opendev.org/c/openstack/nova/+/794345 | |
| 10:58:41 | slaweq | gibi elodilles hi, do You know about any known issues in nova-grenade-multinode job on stable/victoria? | |
| 10:58:53 | slaweq | I'm trying to merge https://review.opendev.org/c/openstack/nova/+/787252 but it's failing all the time for me | |
| 10:59:12 | slaweq | and I'm not sure if it's just my bad luck or there is any issue with that job already | |
| 11:36:24 | elodilles | slaweq: yes, see my previous 2 lines above :) | |
| 11:37:12 | elodilles | slaweq: and the mail about it: http://lists.openstack.org/pipermail/openstack-discuss/2021-June/022900.html | |
| 11:37:50 | elodilles | so hopefully the gate will work again, soon :) | |
| 11:39:13 | slaweq | elodilles thx a lot | |
| 11:39:27 | slaweq | and sorry that I didn't check channel logs before asking :) | |
| 11:53:20 | elodilles | slaweq: no problem :) and thanks for pushing those backports ;) | |
| 11:59:09 | lyarwood | elodilles: ack looking | |
| 12:01:55 | elodilles | lyarwood: thanks! :) | |
| 12:32:17 | bauzas | lyarwood: elodilles: sorry was getting my 2nd vaccine jab | |
| 12:38:53 | opendevreview | Lee Yarwood proposed openstack/nova master: libvirt: fup docs and typing for _hard_reboot flow https://review.opendev.org/c/openstack/nova/+/795081 | |
| 12:39:31 | elodilles | bauzas: np :) | |
| 12:44:34 | opendevreview | Lee Yarwood proposed openstack/nova master: libvirt: Set driver_iommu when attaching virtio devices to SEV instance https://review.opendev.org/c/openstack/nova/+/794639 | |
| 13:04:09 | opendevreview | John Garbutt proposed openstack/nova-specs master: Re-propose Unified Limits in Nova https://review.opendev.org/c/openstack/nova-specs/+/789585 | |
| 13:50:50 | opendevreview | John Garbutt proposed openstack/nova master: Add legacy limits and usage to unified limits https://review.opendev.org/c/openstack/nova/+/713498 | |
| 13:56:15 | lyarwood | gibi, bauzas ; can I get reviews on https://review.opendev.org/c/openstack/nova/+/794639 please? Trying to set SEV QE'd downstream and hit this roadblock | |
| 13:56:28 | bauzas | lyarwood: sure, I can take a look | |
| 13:56:55 | lyarwood | hmmm the LC job still isn't happy with something | |
| 13:57:42 | kashyap | LC? | |
| 13:58:13 | lyarwood | lower constraints | |
| 13:58:15 | kashyap | Maybe you mean "Live Migration Ceph" | |
| 13:58:35 | kashyap | Oh, right. The LM Ceph job is non-voting | |
| 13:58:55 | bauzas | lyarwood: I guess we don't have yet functional tests for SEV instances ? | |
| 13:59:19 | bauzas | lyarwood: I was wondering about a regression test but if not, fair. | |
| 14:00:48 | lyarwood | I can land some tests after this but backporting functional tests to stable/train is a royal PITA at the moment | |
| 14:01:08 | lyarwood | there's an actual issue with this that didn't come up in the unit tests btw | |
| 14:01:13 | lyarwood | but somehow the LC job caught it | |
| 14:02:01 | lyarwood | during a live migration we pass the _get_volume_config method around and end up calling it from nova.virt.libvirt.migration._update_volume_xml without access to the instance, borking the approach I've taken | |
| 14:02:15 | kashyap | bauzas: Also ... as you know, to meaningfully test SEV, you need real hardware | |
| 14:02:16 | lyarwood | I'll correct and respin now | |
| 14:02:32 | lyarwood | kashyap: well not functional, that's the entire point | |
| 14:02:45 | bauzas | lyarwood: yeah I wasn't asking about a functtest in the main change, sorry | |
| 14:02:55 | kashyap | lyarwood: Right; I realize. "Functional" in Nova still does some stubbing, right? | |
| 14:03:04 | bauzas | lyarwood: something like a separate patch we could use for verifying this works | |
| 14:03:34 | kashyap | lyarwood: Anyway...don't want to dissuade you from any tests you have in mind | |
| 14:03:35 | lyarwood | kashyap: yeah and here we are just asserting things about the XML we are providing libvirt | |
| 14:03:42 | bauzas | lyarwood: like we actually do for virtual GPUs for example | |
| 14:03:49 | kashyap | lyarwood: Yeah, for that part, it's fair enough | |
| 14:27:05 | opendevreview | John Garbutt proposed openstack/nova master: Enforce api and db limits https://review.opendev.org/c/openstack/nova/+/712142 | |
| 14:37:32 | opendevreview | John Garbutt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/c/openstack/nova/+/712143 | |
| 14:39:01 | opendevreview | John Garbutt proposed openstack/nova master: Update limit APIs https://review.opendev.org/c/openstack/nova/+/712707 | |
| 14:41:56 | opendevreview | John Garbutt proposed openstack/nova master: Update quota sets APIs https://review.opendev.org/c/openstack/nova/+/712749 | |
| 15:17:50 | artom | When was the last time we talked about preemptible instances? (Most recent) Denver? | |
| 15:18:05 | artom | Anyone remember the outcome? | |
| 15:26:53 | opendevreview | Kashyap Chamarthy proposed openstack/nova master: Allow 'bochs' as a display device option https://review.opendev.org/c/openstack/nova/+/794796 | |
| 15:28:20 | kashyap | artom: Hey, completely unrelated: did I miss anything else to bump in the above? (I'm pinging you, as you did something similar for your "socket" (for PCI NUMA affinity) thingie) | |
| 15:28:38 | artom | kashyap, lemme check | |
| 15:29:50 | kashyap | artom: Hmm, okay ... this is the one failing test: http://paste.openstack.org/show/806427/. How do I update that hash? | |
| 15:30:02 | opendevreview | Lee Yarwood proposed openstack/nova master: libvirt: Set driver_iommu when attaching virtio devices to SEV instance https://review.opendev.org/c/openstack/nova/+/794639 | |
| 15:30:30 | artom | kashyap, it's in nova/tests/unit/objects/test_objects.py - just grep for the old 'reference' hash, and change it to the new one | |
| 15:31:46 | kashyap | artom: Okay, a stupid question: where do I "discover" the new hash? | |
| 15:31:57 | artom | kashyap, you don't, the tests will tell you :) | |
| 15:32:08 | artom | At least that's what I always do. | |
| 15:32:15 | kashyap | Ah, right; it should catch it | |
| 15:32:34 | kashyap | artom: Okay, that's good. Lemme try | |
| 15:32:41 | artom | Any time I change objects, I try to remember to run test_objects, then update the hashes. | |
| 15:33:44 | kashyap | artom: You mean 'test_versions'? | |
| 15:33:51 | kashyap | But yeah, point noted... | |
| 15:35:11 | kashyap | artom: Thanks. | |
| 15:36:01 | artom | kashyap, well, test_versions in test_objects.py | |
| 15:37:18 | kashyap | Yep; yar. | |
| 15:38:27 | kashyap | Alright, that fixes it | |
| 15:42:16 | opendevreview | Kashyap Chamarthy proposed openstack/nova master: Allow 'bochs' as a display device option https://review.opendev.org/c/openstack/nova/+/794796 | |
| 15:52:02 | bauzas | artom: about preemptible instances, we said "go for it" | |
| 15:52:11 | bauzas | but not something in Nova | |
| 15:52:27 | bauzas | a specific other service, and it was maybe Blazar | |
| 15:52:40 | bauzas | priteau: do you remember when and where we said this ? | |
| 15:52:40 | artom | IIRC there was a thing called "Reaper"? | |
| 15:53:01 | bauzas | artom: correct, something done by john and the CERN IIRC | |
| 15:53:52 | bauzas | I remember this https://specs.openstack.org/openstack/blazar-specs/specs/ussuri/blazar-preemptible-instances.html | |
| 15:54:07 | priteau | bauzas: I think we mentioned the reaper in Blazar in Denver PTG (Sep 2018) | |
| 15:54:23 | opendevreview | Lee Yarwood proposed openstack/nova-specs master: Add attachmentId to responses of the os-volume_attachments API https://review.opendev.org/c/openstack/nova-specs/+/794799 | |
| 15:54:58 | kashyap | artom: When you can, please give your ack (or nack, if need be) again? I uploaded a rev right after you did. | |
| 15:55:17 | priteau | bauzas: but that was maybe before aardvark was completed | |
| 15:56:18 | lyarwood | https://review.opendev.org/c/openstack/nova/+/793463 should be ready for review if anyone has time btw | |
| 15:56:30 | bauzas | priteau: this one, right? https://gitlab.cern.ch/ttsiouts/aardvark | |
| 15:56:33 | bauzas | artom: ^ | |
| 15:56:38 | priteau | yep | |
| 15:58:07 | artom | Is https://gitlab.cern.ch/ttsiouts/aardvark the continuation of https://gitlab.cern.ch/ttsiouts/ReaperServicePrototype? | |
| 15:58:12 | artom | Also, both look fairly dead | |
| 16:10:29 | priteau | artom: I believe it the continuation, yes. Unfortunately ttsiouts has left CERN and I don't believe this work has been picked up by anyone else. | |
| 16:10:56 | priteau | Also I think there were some disagreement on the nova modifications required for this (pending state) | |
| 16:11:36 | artom | priteau, ack, thanks for the context! | |
| 16:11:42 | artom | priteau, are you with CERN, btw? | |
| 16:15:02 | priteau | I am not, but I work with John Garbutt at StackHPC who I think was involved in the discussions | |