| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-04 | |||
| 11:30:23 | sean-k-mooney | kashyap: that is allowed to a point. we do not allow the use of the qemu:args element to be genearted to allow raw qemu commands to be added | |
| 11:30:41 | mdbooth | lyarwood: Did you speak to mriedem about removing the timestamp check from the retype tempest test? | |
| 11:30:55 | sean-k-mooney | kashyap: i have tried in the past to enable features that are not supported by libvirt yet or on older versions | |
| 11:31:33 | mdbooth | I'll take your work for it that they're flaky, but IIUC the purpose was to assert functionally that the volume contains the same data after retype. | |
| 11:31:56 | mdbooth | lyarwood: IIRC mriedem was especially keen on this. | |
| 11:32:51 | lyarwood | mdbooth: I had no idea he was attached to it tbh | |
| 11:32:57 | lyarwood | mdbooth: I'll bring it up with him this afternoon | |
| 11:33:13 | lyarwood | mdbooth: and yeah it has been pretty awful for me locally testing this | |
| 11:33:40 | mdbooth | Yeah, I can imagine. Seems to work ok in the gate, though. | |
| 11:34:07 | kashyap | sean-k-mooney: Yeah, that's what I meant: Nova not allowing libvirt's <qemu:commandline> element which allows arbitrary pass-through. | |
| 11:34:32 | sean-k-mooney | yep that is the element i was thinking of | |
| 11:34:34 | kashyap | sean-k-mooney: (And yeah, I've used it for one-off hacks in Nova in the past.) | |
| 11:35:37 | sean-k-mooney | ya i used it to demonstarte that you can run ovs-dpdk without hugepages before i got funding to have the libvirt support for file backed memory developed | |
| 11:36:28 | sean-k-mooney | i never got time to add the nova support for file backed memory the way i wanted it but redhat did it a release or two later for other uses | |
| 11:38:12 | sean-k-mooney | <qemu:commandline> is still useful for POCs of thing that will be comming soon so you can write the nova side of the feature and just swap out the xml generation code when it lands in libvirt | |
| 11:39:20 | kashyap | sean-k-mooney: Yeah, is useful in many scenarios; I consider it as a Swiss Army knife. | |
| 11:49:00 | gibi | sean-k-mooney: thanks. I think I will skip the xen support now due to the shortness of time. But I feel that I will manage to push the libvirt support today | |
| 11:51:22 | sean-k-mooney | gibi: good to hear. i ended up spending my weekend hacking time on figuring out how to get vs-code to debug eventlet code which i did but as a result i didnt get much time to look at the auto generation | |
| 11:51:49 | gibi | sean-k-mooney: no worries you helped a lot by point out the code pieces I need | |
| 11:54:32 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add compute service support for attach/detach root volume https://review.openstack.org/614750 | |
| 12:10:17 | cdent | thanks for the response mdbooth, I was doing a run through of patches that touch vmware related stuff (there's an automated thingie that tells me about such stuff). I wasn't sure of the state of that one | |
| 12:10:31 | mdbooth | cdent: thanks | |
| 12:13:35 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Detach/Attach root volume API changes https://review.openstack.org/623981 | |
| 12:53:18 | kashyap | aspiers: Have you noticed this: https://www.redhat.com/archives/libvir-list/2019-February/msg01730.html (New Feature: Intel MKTME Support) | |
| 12:53:39 | kashyap | aspiers: It ("MKTME": Multi-Key Total Memory Encryption) is Intel's equivalent to AMD SEV | |
| 12:54:15 | aspiers | kashyap: ah interesting, so another alternative to the SGX approach? | |
| 12:54:59 | kashyap | aspiers: I don't know much (if anything) about Intel's SGX | |
| 12:55:26 | kashyap | aspiers: But the MKTME isn't yet merged in the kernel (https://lwn.net/Articles/758313/) | |
| 12:55:29 | kashyap | (Near as I see) | |
| 12:55:43 | kashyap | s/MKTME/"Support for MKTME"/ | |
| 12:55:59 | sean-k-mooney | SGX is intels secure enclave technology that prevent the host kernel and userpace processes form acessing meory that is in the enclave and assigend to a specifc process | |
| 12:57:27 | sean-k-mooney | the SGX enclaves are created and managed via system management mode so even the host kernel cannot read or write to if it is not the owner of the enclve but i dont be think SGX actully encrypts the memory | |
| 12:57:52 | kashyap | sean-k-mooney: Ah, thanks for the nice summary | |
| 12:59:23 | sean-k-mooney | so sgx + mktme would give someting simlar but maybe more secure then SEV as teh memory is not just encrypted but partitioned | |
| 12:59:40 | sean-k-mooney | i dont realy know anyting about mktme however | |
| 13:01:01 | artom | ~o~ | |
| 13:01:59 | mdbooth | Perhaps there's some super-small ring -1 which is allowed to do context switches? | |
| 13:04:54 | sean-k-mooney | mdbooth: by the way https://review.openstack.org/#/c/634276/ may have been related to some of the port binding issue you were having with failed migrations | |
| 13:06:10 | mdbooth | sean-k-mooney: Nice, thanks. | |
| 13:09:04 | sean-k-mooney | mdbooth:for sgx. i dont think so. memory in sgx enclaves is not swapable. so other the createing and destroying them there isnt anything that a ring -1 e.g. hypervior layer process would need to do | |
| 13:12:46 | sean-k-mooney | as far as i know the sgx enclaves are mapped into the process virtual memory via the iommu. as such i dont think there is a context switch requried for a process to acess it. that said its been 2 years since i looked at how sgx worked in detail | |
| 13:14:01 | mdbooth | lyarwood: https://review.openstack.org/#/c/639331/ | |
| 13:14:17 | mdbooth | lyarwood: I'd like to get mriedem's opinion on that. | |
| 13:15:43 | mdbooth | Grr, gerrit seems to bogosort the results of a change query. The order changes every time I look at it. | |
| 13:20:05 | openstackgerrit | Merged openstack/nova stable/rocky: Fix legacy-grenade-dsvm-neutron-multinode-live-migration https://review.openstack.org/640186 | |
| 13:20:15 | openstackgerrit | Merged openstack/nova master: api-ref: explain aggregate set_metadata semantics https://review.openstack.org/640460 | |
| 13:20:23 | openstackgerrit | Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104 | |
| 13:26:04 | lyarwood | mdbooth: sorry was on the phone | |
| 13:26:10 | lyarwood | mdbooth: ack thanks | |
| 13:26:37 | mdbooth | lyarwood: You've had the same failure 3 times in a row on the migration tempest test, btw. | |
| 13:26:50 | mdbooth | lyarwood: failure to delete type because it's still in use. | |
| 13:26:53 | lyarwood | mdbooth: yeah clean up is racing | |
| 13:26:56 | mdbooth | Have you investigated that already? | |
| 13:27:05 | lyarwood | mdbooth: next on my list | |
| 14:00:28 | openstackgerrit | Merged openstack/nova master: Fixes race condition with privsep utime https://review.openstack.org/625741 | |
| 14:00:39 | efried | n-sch meeting now in #openstack-meeting-alt | |
| 14:04:29 | openstackgerrit | Merged openstack/nova master: Optimize populate_queued_for_delete online data migration https://review.openstack.org/639840 | |
| 14:04:36 | openstackgerrit | Merged openstack/nova master: Remove wrong description for auto resize confirm https://review.openstack.org/638357 | |
| 14:04:43 | openstackgerrit | Merged openstack/nova stable/rocky: Fix overcommit for NUMA-based instances https://review.openstack.org/633197 | |
| 14:24:48 | openstackgerrit | Jim Rollenhagen proposed openstack/nova stable/rocky: ironic: stop hammering ironic API in power sync loop https://review.openstack.org/640771 | |
| 14:24:48 | openstackgerrit | Jim Rollenhagen proposed openstack/nova stable/rocky: ironic: check fresh data when sync_power_state doesn't line up https://review.openstack.org/640772 | |
| 14:25:07 | jroll | turns out we never backported that first one >.> | |
| 14:32:28 | stephenfin | lyarwood: Could you look at https://review.openstack.org/#/c/636919/ today? | |
| 14:37:07 | mriedem | who's ready to rush some crap in | |
| 14:38:04 | sean-k-mooney | i dont know its only monday :P we have 3 whole days left to rush crap in | |
| 14:39:25 | stephenfin | mriedem: Just tell me what I need to blindly +W | |
| 14:44:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add nits from Id2beaa7c4e5780199298f8e58fb6c7005e420a69 https://review.openstack.org/640729 | |
| 14:44:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: Rework 'config-drive' user doc https://review.openstack.org/640730 | |
| 14:49:04 | openstackgerrit | Yongli He proposed openstack/nova master: Add server sub-resource topology API https://review.openstack.org/621476 | |
| 14:53:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Store InstancePCIRequest.numa_policy in DB https://review.openstack.org/624444 | |
| 14:53:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: fakelibvirt: Add ability to generate fake PCI devices https://review.openstack.org/640409 | |
| 14:56:49 | mriedem | sounds like a nightmare to me | |
| 14:57:40 | bauzas | mriedem: give me some crap, I'm thirsty | |
| 15:00:28 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: qemu: Make disk image conversion dramatically faster https://review.openstack.org/640781 | |
| 15:00:42 | kashyap | mdbooth: ^ If you have time. | |
| 15:01:38 | kashyap | (Change itself is a "one-worder"; but the commit message is long, with a back-of-the-envelope "benchmark" & context) | |
| 15:13:36 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543 | |
| 15:13:37 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360 | |
| 15:14:02 | gibi | sean-k-mooney, stephenfin: removed the whitelis tag config extension and added the auto detection of the pf interface name ^^ | |
| 15:16:01 | gibi | any feedback are welcome | |
| 15:16:41 | artom | mriedem, well, *my* crap is going to remain unrushed, and will smell delicious by the time it lands ;) | |
| 15:17:14 | artom | efried, btw, I'm +1 on https://review.openstack.org/#/c/635440/9, but I left a question inline | |
| 15:20:22 | mriedem | umm, what actually puts the instance into ERROR state in ^? | |
| 15:22:02 | artom | Gremlins? | |
| 15:22:24 | jroll | .v 37 | |
| 15:22:29 | jroll | blurhg, sorry | |
| 15:22:35 | kashyap | :D | |
| 15:23:11 | cfriesen | sean-k-mooney: is it expected that PCI aliases will be configured in the nova-api nova.conf the same as all compute nodes? | |
| 15:23:26 | sean-k-mooney | yes | |
| 15:23:35 | cfriesen | mriedem: there you go ^ | |
| 15:25:26 | mriedem | isn't that....weird? | |
| 15:25:46 | mriedem | the computes can have different pci devices right? so wouldn't the alias config be per-compute? | |
| 15:29:37 | cfriesen | mriedem: I assume the idea is that a given alias should mean the same thing across the whole cloud, even if not all computes have that device. | |
| 15:31:21 | mriedem | ok i guess it's true https://docs.openstack.org/nova/latest/admin/pci-passthrough.html#configure-nova-api-controller | |
| 15:31:25 | mriedem | and documented that way | |
| 15:31:32 | sean-k-mooney | mriedem: it is weird but its needed for reasons | |
| 15:31:43 | sean-k-mooney | im trying to rememebr why | |
| 15:31:51 | sean-k-mooney | stephenfin: do you rememebr ? | |
| 15:32:23 | sean-k-mooney | i think i had something to do with either hardwar offloaded ovs or pci numa policies | |
| 15:33:09 | stephenfin | sean-k-mooney: Why they have to be specified on the API node? | |