| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-15 | |||
| 10:45:45 | kashyap | Cool, you're using the MTTCG backend | |
| 10:46:16 | sean-k-mooney | ya unfortunetly libvirt decided not to expose an xml element for it | |
| 10:46:38 | sean-k-mooney | so the best we can do is to use a cpu model that support mttcg | |
| 10:46:48 | kashyap | File an RFE for libvirt, if you see a valid use? | |
| 10:46:52 | sean-k-mooney | qemu64 should fit that requirement | |
| 10:47:19 | sean-k-mooney | kashyap: they intentionally chose not to but i think it makes consumtion in openstack harder | |
| 10:47:24 | kashyap | (But 'qemu64' is also an awful CPU to use in general (I know we're just testing) :-( -- because it can't get the Spectre/Meltdown fixes) | |
| 10:47:39 | sean-k-mooney | kashyap: it does not need them | |
| 10:47:41 | kashyap | TODO: Move away from 'qemu64' even for testing | |
| 10:48:05 | sean-k-mooney | kashyap: its an emulated cpu and therefor should not need to emulate the vulnerablity | |
| 10:48:28 | sean-k-mooney | you can fix specter and meltdown entirely in qemu for qemu64 | |
| 10:48:46 | sean-k-mooney | if they havent that is a qemu bug | |
| 10:49:04 | sean-k-mooney | so i dont see any reason to move away form qemu64 for testing | |
| 10:49:34 | kashyap | sean-k-mooney: So back to that MTTCG thing, I saw the rationale on the libvirt list: | |
| 10:49:37 | kashyap | [quote] | |
| 10:49:40 | kashyap | We don't have anything in the domain XML that indicates | |
| 10:49:42 | kashyap | whether a guest is using TCG or MTTCG. While QEMU does | |
| 10:49:44 | kashyap | have an option (-accel tcg,thread=single|multi), it is | |
| 10:49:47 | kashyap | not desirable to expose this in libvirt. QEMU will | |
| 10:49:49 | sean-k-mooney | yes i know i read it | |
| 10:49:49 | kashyap | automatically use MTTCG when the host/guest architecture | |
| 10:49:52 | kashyap | pairing is known to be safe. Only developers of QEMU TCG | |
| 10:49:52 | kashyap | Ah, okay | |
| 10:49:54 | kashyap | have a strong reason to override this logic. | |
| 10:49:57 | kashyap | [/quote] | |
| 10:49:59 | kashyap | It is reasonable | |
| 10:50:00 | stephenfin | sean-k-mooney: Came up with something even better (IMO) | |
| 10:50:05 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hacking: Resolve E731 (do not assign a lambda expression, use a def) https://review.openstack.org/651554 | |
| 10:50:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hacking: Resolve W503 (line break occurred before a binary operator) https://review.openstack.org/651555 | |
| 10:50:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hacking: Resolve E741 (ambiguous variable name) https://review.openstack.org/652103 | |
| 10:50:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: hacking: Resolve W605 (invalid escape sequence) https://review.openstack.org/652104 | |
| 10:50:20 | sean-k-mooney | kashyap: i dont think so | |
| 10:50:25 | stephenfin | back to real work | |
| 10:50:48 | sean-k-mooney | kashyap: we really want to know if its enabeld or not so we can fail to boot the vm if its not | |
| 10:51:30 | kashyap | Hmm. Then file a libvirt RFE telling a management tool has a user for it :-) | |
| 10:52:03 | sean-k-mooney | i could i was going to ping dan donwstream and get his input first. | |
| 10:52:49 | sean-k-mooney | kashyap: i had stared working on enableing mttcg as a new virt_type when i came across the ml post where they said it was not exposed | |
| 10:53:19 | sean-k-mooney | but anyway that can wait. | |
| 10:53:30 | sean-k-mooney | stephenfin: do you have a like to your fixed version? | |
| 10:53:47 | sean-k-mooney | actully never mind ill jsut refresh :) | |
| 10:53:57 | stephenfin | yeah, it's the one I just pushed there :) | |
| 10:55:02 | sean-k-mooney | i mean it works. i still dislike you using variable form the enclosing scope but ya it should work | |
| 10:55:14 | sean-k-mooney | and you dont have to change the call site | |
| 10:57:02 | sean-k-mooney | stephenfin: do we still have cases where the service id is not a uuid by the way? | |
| 10:58:20 | kashyap | sean-k-mooney: On your comment that: upstream QEMU should fix 'qemu64' entirely for Spectre/Meltdown. It's a non-goal: | |
| 10:58:23 | kashyap | "TCG is not suitable for containing malicious code, so we don't need to worry about hardening against guests using spectre to exploit the JIT" | |
| 10:58:38 | sean-k-mooney | kashyap: by the way one of the reasons i was interested in teh mttcg backend was the ability to emulate other achitecutres without the horible performacne cost | |
| 10:58:58 | kashyap | sean-k-mooney: Yeah, can imagine (on MTTCG) | |
| 10:59:00 | sean-k-mooney | kashyap: :( | |
| 10:59:52 | kashyap | sean-k-mooney: I don't think it's (no security guarantees for TCG) an issue for us: as the upstream CI isn't running any real workloads in the L2 | |
| 10:59:59 | sean-k-mooney | you can do it today by using a custom cpu_model + setting the machine type and qemu backend | |
| 11:00:15 | sean-k-mooney | kashyap: ya | |
| 11:00:22 | kashyap | (So we're good, there.) | |
| 11:00:39 | sean-k-mooney | the reason i went for qemu64 was to make sure it could run on all the ci cloud providers | |
| 11:00:45 | sean-k-mooney | event the xen based ones | |
| 11:01:05 | sean-k-mooney | and it should be supported by mttcg as it uses the smallest feature set | |
| 11:02:59 | sean-k-mooney | stephenfin: by the way looking at https://review.openstack.org/#/c/652197/7/playbooks/nfv/nfv.yaml can you think of an epa/numa feature i have missed beyond 2 numa nodes? | |
| 11:04:03 | sean-k-mooney | stephenfin: im going to test ovs-dpdk in a different job | |
| 11:06:54 | openstackgerrit | Merged openstack/nova stable/stein: Adding tests to demonstrate bug #1821824 https://review.openstack.org/649600 | |
| 11:06:56 | openstack | bug 1821824 in OpenStack Compute (nova) stein "Forbidden traits in flavor properties don't work" [High,In progress] https://launchpad.net/bugs/1821824 - Assigned to Eric Fried (efried) | |
| 11:29:36 | openstackgerrit | Merged openstack/nova stable/stein: Fix bug preventing forbidden traits from working https://review.openstack.org/649601 | |
| 11:30:17 | sean-k-mooney | :) ^ | |
| 11:31:13 | sean-k-mooney | cool its already proposed to be backported to rocky as well :) | |
| 11:54:31 | openstackgerrit | Merged openstack/python-novaclient stable/stein: Add test for console-log and docs for bug 1746534 https://review.openstack.org/651925 | |
| 11:54:33 | openstack | bug 1746534 in python-novaclient "encoding error when doing console-log" [High,Fix released] https://launchpad.net/bugs/1746534 - Assigned to Thomas Goirand (thomas-goirand) | |
| 12:14:10 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Server move operations with ports having resource request https://review.openstack.org/652608 | |
| 12:35:57 | kashyap | gibi: Does this require a Blueprint (much less a "spec"): https://bugs.launchpad.net/nova/+bug/1789868 | |
| 12:35:58 | openstack | Launchpad bug 1789868 in OpenStack Compute (nova) "RFE: Add a virtio-rng device to Nova instances by default" [Medium,In progress] - Assigned to s10 (vlad-esten) | |
| 12:37:02 | kashyap | I'd actually classify it as a "bug". But, whatever :-) (We already have a patch up for it, though: https://review.openstack.org/#/c/616603/) | |
| 12:46:16 | gibi | kashyap: I'm fine going with that bug report | |
| 12:46:25 | kashyap | gibi: Ah, okay, then. | |
| 12:47:20 | gibi | kashyap: just a question. Could this change cause that on guest can deplete the enthropy pool of the host and therefore cause troubles on the host or in other guests? | |
| 12:47:28 | kashyap | Wasn't sure if the 'process hammer' would come to bite me in the behind ... | |
| 12:47:40 | gibi | kashyap: at least not my process hammer... | |
| 12:47:48 | kashyap | (Heh) | |
| 12:47:58 | kashyap | gibi: No, it won't. But let me quadruple-check with the RNG experts | |
| 12:52:42 | kashyap | gibi: Confirmed: One guest can't do that. | |
| 12:52:54 | kashyap | Where "that" == deplete the entropy pool of the host | |
| 12:55:30 | gibi | kashyap: OK. thanks | |
| 13:04:00 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add TODO to remove function attribute https://review.openstack.org/652649 | |
| 13:05:10 | stephenfin | gibi: If you have a chance, could you look at https://review.openstack.org/#/c/651302/1/nova/objects/instance.py and see if I'm doing anything particular wrong? | |
| 13:07:57 | kukacz | hi, I wonder if nova handles situation of live-migrating an instance with config drive from rbd-backed compute host to file-backed compute host and vice versa? it seems I'm stuck in Ocata with instance resized from rbd-backed to raw-backed compute node, not willing to live-migrate in the other direction | |
| 13:09:00 | kukacz | it's a volume-booted instance. the issue is about config drive | |
| 13:19:37 | gibi | stephenfin: replied to the notification part. I wasn't to helpful, sorry. | |
| 13:19:53 | stephenfin | gibi: Neither was I so that makes two of us. Thanks :) | |
| 13:21:22 | gibi | stephenfin: I think you need dansmith for this | |
| 13:37:46 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Undeprecate and move the 'dhcp_domain' option https://review.openstack.org/480616 | |
| 13:37:46 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Handle unsetting '[DEFAULT] dhcp_domain' https://review.openstack.org/652662 | |
| 13:43:48 | efried | boxiang: Do you mind if I do a quick edit of https://review.openstack.org/#/c/645458/ for grammar? | |
| 13:51:08 | mriedem | lyarwood: questions in your swap volume migration_status patch https://review.openstack.org/#/c/637224/ | |
| 13:51:16 | mriedem | lyarwood: looks like there could be some weird edge cases | |
| 13:58:56 | mriedem | efried: please don't since there are major issues now in that spec | |
| 13:59:10 | mriedem | i.e. persisting RequestSpec.requested_destination now | |
| 13:59:21 | mriedem | please dear sweet baby jesus in heaven no | |
| 13:59:21 | efried | mriedem: Yup, Above comment was before those came in. So now I'll just mark up the issues so boxiang can fix them on the next spin. | |
| 13:59:28 | boxiang | efried: ok | |
| 13:59:44 | efried | mriedem: Did you see the discussion between boxiang and alex_xu in PS13 on persisting? | |
| 13:59:50 | mriedem | yes, and i disagree | |
| 13:59:52 | mriedem | i'm commenting | |
| 14:00:01 | cdent | placement meeting in now ish in #openstack-meeting-alt | |