| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-04 | |||
| 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: check fresh data when sync_power_state doesn't line up https://review.openstack.org/640772 | |
| 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: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: WIP: fakelibvirt: Add ability to generate fake PCI devices https://review.openstack.org/640409 | |
| 14:53:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Store InstancePCIRequest.numa_policy in DB https://review.openstack.org/624444 | |
| 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? | |
| 15:33:16 | sean-k-mooney | cfriesen: it was related to scheduling. we needed the content of teh alias to aloow the schulers to make desissions | |
| 15:33:21 | sean-k-mooney | stephenfin: yes | |
| 15:33:47 | sean-k-mooney | i think it was so the numa toplogy filter could take the pci_numa policy into effect | |
| 15:34:08 | cfriesen | I'm not complaining, it's helpful for the flavor/image validation. :) | |
| 15:34:11 | stephenfin | Nah, it's because it's needed for move operations | |
| 15:34:16 | stephenfin | See b4ce2d9f12ef6d50837e4133dff09fa43fd152d2 | |
| 15:35:38 | sean-k-mooney | stephenfin: well the move operations e.g. cold migration need it for schudleing | |
| 15:37:05 | sean-k-mooney | mriedem: the alias does not contain the pci addresses. so it works independenly form the compute nodes for most usecause | |
| 15:38:09 | sean-k-mooney | it does mean if you put the pci vendor and product id in the alias that it has to match across the compute nodes but you are better off haveing 1 alias per device model anyway | |
| 15:41:45 | mriedem | sure | |
| 15:42:13 | mriedem | artom: btw, how is your downstream numa live migration whitebox tempest testing stuff passing if the intel people testing it are finding issues? just different issues from what the CI would hit? | |
| 15:42:45 | sean-k-mooney | mriedem: i responded on the mailing list | |
| 15:43:03 | sean-k-mooney | mriedem: they were using virsh edit to view the xml instead of virsh dumpxml | |
| 15:43:15 | sean-k-mooney | virsh dumpxml shows the current state of the vm | |
| 15:43:32 | sean-k-mooney | virsh edit shows the xml that the vm would have it you were to reboot it | |
| 15:44:00 | sean-k-mooney | it looks like when we update the xml as part of a migration virsh edit still shows the original xml | |
| 15:44:33 | sean-k-mooney | so that is the reason for the delta. the whitebox test use virsh dumpxml which i belive is correct | |
| 15:52:53 | mriedem | (8:39:26 AM) stephenfin: mriedem: Just tell me what I need to blindly +W | |
| 15:53:05 | mriedem | stephenfin: don't go blind on this, but https://review.openstack.org/#/c/623543/ | |
| 15:53:18 | mriedem | since gibi abandoned https://review.openstack.org/#/c/625311/ | |