| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-15 | |||
| 10:24:36 | sean-k-mooney | aspiers: have you added it to the review day etherpad | |
| 10:24:44 | sean-k-mooney | i think it was there last week | |
| 10:25:07 | stephenfin | Can someone sanity check this and tell me how I've changed the logic? https://review.openstack.org/#/c/651554/3/nova/compute/api.py | |
| 10:25:31 | stephenfin | (tests are failing so I've obviously broken _something http://logs.openstack.org/54/651554/3/check/openstack-tox-py27/d5489c5/testr_results.html.gz) | |
| 10:25:32 | aspiers | sean-k-mooney: I am definitely intending to - I thought it wasn't really ready for more feedback yet until we address the existing concerns | |
| 10:25:44 | sean-k-mooney | stephenfin: looking | |
| 10:25:57 | aspiers | sean-k-mooney: my new patchset will be mostly just including the new info and suggestions from you / Daniel / Brijesh | |
| 10:26:59 | sean-k-mooney | stephenfin: im gessing the addtion of " and service_host is none" | |
| 10:27:29 | stephenfin | That reads to me like I'm moving the third case in the if-else to the first | |
| 10:27:31 | sean-k-mooney | actully no that is just the else block | |
| 10:27:34 | stephenfin | yeah | |
| 10:28:20 | sean-k-mooney | stephenfin: where do you call the new lookup_fn fucntion | |
| 10:28:37 | stephenfin | sean-k-mooney: line 5002 on the right | |
| 10:28:43 | stephenfin | maybe the 'target_cell' context manager is doing something weird? :/ | |
| 10:29:24 | sean-k-mooney | it shouldnt | |
| 10:30:25 | sean-k-mooney | why are you doing this refactoring by the way. to get rid of the pep8 warning about lamdas should not be named? | |
| 10:30:46 | stephenfin | sean-k-mooney: Yeah. I was going to noqa that particular one but for some reason I can't do that | |
| 10:32:11 | sean-k-mooney | stephenfin: why are you not passing in service_id by the way | |
| 10:32:42 | stephenfin | where now? | |
| 10:33:04 | sean-k-mooney | https://review.openstack.org/#/c/651554/3/nova/compute/api.py@4989 | |
| 10:34:11 | stephenfin | sean-k-mooney: You don't need to for nested functions. They have access to everything in their parent's | |
| 10:34:19 | kashyap | stephenfin: Hey there, an rST references question: just by looking at this rendering, can you tell why the '7' and '8' are funny like that? -- https://kashyapc.fedorapeople.org/Broken-rST-references.png | |
| 10:34:31 | sean-k-mooney | they do but it might mess with mocking | |
| 10:35:18 | stephenfin | kashyap: Not a clue. That's rather odd looking. Indentation is usually the #1 cause of odd stuff like that though | |
| 10:35:32 | kashyap | Ah, I know! | |
| 10:35:40 | kashyap | stephenfin: They're both referenced _twice_ in the document | |
| 10:36:01 | stephenfin | Oh, that's interesting | |
| 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 | |