| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 21:20:53 | aspiers | I hope I can still find an excuse to spend time in the nova room though | |
| 21:21:05 | aspiers | invent some more SEV problems for us to solve together ;-) | |
| 21:21:16 | aspiers | well I guess there's still the implementation haha | |
| 21:21:27 | aspiers | I'll just hack away in a corner and occasionally ask stupid questions | |
| 21:21:32 | sean-k-mooney | add numa to the spec somewhere. it will delay it by a decade | |
| 21:21:34 | efried | Compute capabilities traits placement request filter (mriedem) | |
| 21:21:34 | efried | aspiers: You can own this one: | |
| 21:21:39 | aspiers | sean-k-mooney: LOL | |
| 21:21:48 | aspiers | efried: uhoh :) | |
| 21:22:17 | efried | it'll actually be very closely related to what you're doing here. | |
| 21:23:06 | aspiers | well sure that sounds interesting | |
| 21:23:54 | efried | hmph, except for the wrinkle in the existing patch about not being able to get at the multiattach bool from within request_filter.py, the generic solution would be pretty easy there. | |
| 21:24:03 | sean-k-mooney | its also related in a way to the image metadata prefilteing im hoping to work on although not quite the same | |
| 21:24:29 | openstackgerrit | Merged openstack/nova stable/queens: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.opendev.org/640198 | |
| 21:24:33 | sean-k-mooney | anyway looking at the sev spec which i just finsished again. | |
| 21:24:55 | sean-k-mooney | we proably could merge it as is and fixup the last few nits in a follow up patch | |
| 21:25:23 | sean-k-mooney | but that up to ye | |
| 21:25:38 | sean-k-mooney | i didnt see any really blocker anymore | |
| 21:25:48 | aspiers | sean-k-mooney: thanks, just got a few minor tweaks based on last few hours of discussion | |
| 21:25:57 | aspiers | I'll submit one more patch set and hopefully that will be enough | |
| 21:26:29 | sean-k-mooney | on the + side your feature already has excelent documentation | |
| 21:26:52 | aspiers | cool | |
| 21:27:08 | aspiers | oh I already got a response from Brijesh at AMD | |
| 21:27:18 | aspiers | he confirms it's 1 unit per guest | |
| 21:27:26 | sean-k-mooney | excelent | |
| 21:27:35 | aspiers | and there will always be a limit, which can be queried through the CPUID | |
| 21:27:50 | sean-k-mooney | ya that is not surprising | |
| 21:27:52 | efried | always always? | |
| 21:28:01 | efried | like, don't need the conf var always? | |
| 21:28:21 | aspiers | always always a limit | |
| 21:28:22 | aspiers | https://marc.info/?l=qemu-devel&m=155502702424182&w=2 | |
| 21:28:27 | sean-k-mooney | well i think they ment there will alway be a limit in hardware | |
| 21:28:31 | aspiers | yes | |
| 21:28:38 | sean-k-mooney | but not sure that mean we can discover it via cpuid yet | |
| 21:28:50 | aspiers | that patch exposes it in QEMU | |
| 21:29:02 | aspiers | next step would be to expose in libvirt getDomainCapabilities() | |
| 21:29:09 | aspiers | at which point we can get it in nova | |
| 21:29:26 | efried | but that would require a bump in the min qemu version and stuff... | |
| 21:29:35 | efried | which I thought was kind of already what was discussed with danpb | |
| 21:29:55 | sean-k-mooney | ok so we need to cary the config option for at least 2 years | |
| 21:31:15 | aspiers | efried: not just with danpb but already covered in the spec | |
| 21:31:21 | aspiers | sean-k-mooney: yeah most likely | |
| 21:33:13 | sean-k-mooney | jaypipes: thanks for reviewing the sriov mighration pathces :) | |
| 21:33:45 | sean-k-mooney | now if only stephenfin or maybe efried could leave the final +2+w it could merge before the ptg | |
| 21:34:03 | sean-k-mooney | or more importantly before one of the 41 conflicting patches does | |
| 21:34:19 | efried | sean-k-mooney: link please | |
| 21:34:29 | sean-k-mooney | https://review.opendev.org/#/c/629589/27 | |
| 21:34:46 | sean-k-mooney | that and https://review.opendev.org/#/c/620115/35 | |
| 21:34:53 | efried | When you say things like sriov and live migration I immediately think, "I hope someone else has got this." | |
| 21:35:27 | aspiers | sean-k-mooney, efried: BTW funnily enough Brijesh's reply when I asked why there is a limit "We have limited number of slots in memory controller, each slot gets a different encryption key." | |
| 21:35:43 | efried | hah! | |
| 21:35:45 | sean-k-mooney | ya | |
| 21:35:52 | efried | MEM_ENCRYPTION_KEY_SLOTS | |
| 21:36:06 | efried | again, pretty impl specific. Let's stick with CONTEXT | |
| 21:36:17 | aspiers | OK X-D | |
| 21:36:52 | sean-k-mooney | it had to be somthign like that e.g. they what a fix number of keys they coudl handel | |
| 21:36:57 | aspiers | yeah | |
| 21:37:27 | sean-k-mooney | with this kid of thing you donw want those stored in ram which means sticking them in a register file somewhere | |
| 21:37:56 | sean-k-mooney | and you only have so much spcae on a die to add that memory so there will always be a limit like this | |
| 21:38:19 | sean-k-mooney | at least 15/16 is resonable | |
| 21:38:47 | aspiers | right | |
| 21:38:53 | sean-k-mooney | i remember being asked to enable QOS policies with intel QAT devices at one point where the limit was 4 | |
| 21:39:00 | aspiers | haha | |
| 21:39:05 | sean-k-mooney | you could have 32 VF | |
| 21:39:20 | sean-k-mooney | but only 4 QOS policies | |
| 21:39:34 | sean-k-mooney | and it was a 1:1 maping between QOS policey and a singel VF | |
| 21:39:53 | sean-k-mooney | if you used any of the other ones they ignroed the qos policy | |
| 21:40:06 | sean-k-mooney | we never enabeld in in openstack. | |
| 21:40:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: AZ list performance optimization: avoid double service list DB fetch https://review.opendev.org/636947 | |
| 21:40:16 | mriedem | efried: i found and cleaned this up with test wrinkles and addressed some of my own comments ^ let me know if you think it needs more | |
| 21:40:25 | mriedem | but yeah that's a really nice perf improvement from avolkov | |
| 21:41:01 | efried | mriedem: ack, looking. | |
| 21:41:20 | efried | are you recusing yourself from approving at this point? | |
| 21:41:29 | sean-k-mooney | mriedem: ya it look like its about half the time | |
| 21:41:48 | mriedem | efried: not necessarily | |
| 21:41:55 | mriedem | i just added test stuff and some code comments | |
| 21:43:24 | openstackgerrit | Merged openstack/python-novaclient master: Updates for OpenDev transition https://review.opendev.org/654429 | |
| 21:43:45 | sean-k-mooney | ya the delta for what you added is mainly non functional changes | |
| 21:45:09 | sean-k-mooney | so is the main sped up form getting the avilablity zones for jsut the enabled serivces | |
| 21:46:27 | efried | mriedem: lgtm. Why did you switch from monkeypatch to mock.patch? | |
| 21:46:38 | mriedem | so i can count the calls | |
| 21:46:46 | mriedem | silly pants | |
| 21:47:10 | mriedem | sean-k-mooney: it's that we don't get enabled services across 10K hosts twice | |
| 21:47:41 | aspiers | did you folks spot the pysnooper tip? | |
| 21:48:04 | sean-k-mooney | ah | |
| 21:48:11 | sean-k-mooney | ya | |
| 21:48:25 | sean-k-mooney | im not sure if ill end up using it or not but we will see | |
| 21:48:46 | aspiers | it looks pretty nice | |
| 21:52:49 | sean-k-mooney | ya but im not sure it will actully be helpful fo more complicate things. but next time i ned to debug some thing complex and im not usgin a grapical debugger ill give it a try | |
| 21:53:46 | efried | mriedem: oh, stub_out doesn't return the fixture. And apparently MonkeyPatch doesn't have a .mock attribute, like MockPatch does. Remind me why we have stub_out? | |
| 21:53:51 | efried | (rhetorical) | |
| 21:55:34 | gmann | mriedem: RE: on job, yes it will merge the var from parent and derived jobs. | |
| 21:57:25 | gmann | mriedem: few zuul var are not append-able for example files, irrelevant-files etc which are regex not array. but devstack var are all merged from all hierarchy of job | |
| 21:59:44 | mriedem | jaypipes: fat ol -2 on this https://review.opendev.org/#/c/625755/ if you remember it | |
| 21:59:56 | mriedem | efried: to get off mox? | |
| 22:00:24 | mriedem | gmann: yup thanks. i'm now just waiting a few days for ci results. :) | |
| 22:07:08 | sean-k-mooney | mriedem: by the way did you want to review the sriov migrtion stuff or are you happy to leave it to jay and stephen | |
| 22:09:00 | mriedem | want to? | |
| 22:09:11 | mriedem | why don't you have it in a runway if you're looking for reviews? | |
| 22:09:23 | sean-k-mooney | oh good point | |