Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-15
10:36:24 kashyap As in, two occurrences of each. How can I accomplish that without this funnynnes (is it a word?)?
10:36:38 stephenfin *funniness
10:36:44 kashyap Damn, that's what I wrote at first
10:36:46 kashyap Thanks :-)
10:37:08 stephenfin tbh, I've no idea. I would _suspect_ it's a theming thing
10:37:45 stephenfin i.e. there's a reference number then cross references to where they're called, and we're sometimes using the latter where we should be using the former. That's a total guess though
10:37:48 kashyap Hmm, so I have to just reference it once. Okheeee, not a big issue
10:38:01 stephenfin Or just live with that weirdness
10:38:08 stephenfin seeing as it's purely stylistic
10:39:15 kashyap Hehe. I adjusted the text to make-do with just one reference.
10:39:24 kashyap Thanks for your response, though.
10:40:07 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: Add "Secure Boot support for KVM & QEMU guests" spec https://review.openstack.org/506720
10:40:59 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: Add "Secure Boot support for KVM & QEMU guests" spec https://review.openstack.org/506720
10:41:17 sean-k-mooney stephenfin: kashyap by the way i dont know if ye saw my mailing list post but i got this working on saturday https://review.openstack.org/#/c/652197/
10:43:05 stephenfin sean-k-mooney: Aha, sussed it (I think)
10:43:15 stephenfin https://review.openstack.org/#/c/651554/3/nova/compute/api.py@4991
10:43:27 stephenfin sean-k-mooney: https://review.openstack.org/#/c/651554/3/nova/compute/api.py@5011
10:43:52 stephenfin Looks like scoping rules mean variables set in a nested function have their own scope so I need to use something like global
10:44:02 openstackgerrit Balazs Gibizer proposed openstack/nova-specs master: Server move operations with ports having resource request https://review.openstack.org/652608
10:44:31 sean-k-mooney stephenfin: yes they do
10:44:42 sean-k-mooney and no just use mulitple return values
10:45:16 sean-k-mooney return is_uuid, ...
10:45:22 kashyap sean-k-mooney: Yep, saw that fly-by on the list
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 kashyap automatically use MTTCG when the host/guest architecture
10:49:49 sean-k-mooney yes i know i read it
10:49:52 kashyap Ah, okay
10:49:52 kashyap pairing is known to be safe. Only developers of QEMU TCG
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 E741 (ambiguous variable name) https://review.openstack.org/652103
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: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.

Earlier   Later