| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-01 | |||
| 13:06:01 | stephenfin | I mean, I guess we could enforce that if we wanted to but the spec is already too big for its own good. I want to land _something_ :) | |
| 13:06:11 | stephenfin | mriedem: At present, yes | |
| 13:06:40 | stephenfin | mriedem: https://review.openstack.org/#/c/541290/15/specs/rocky/approved/numa-aware-vswitches.rst@405 | |
| 13:06:49 | stephenfin | giblet: Thanks for the reminder | |
| 13:07:04 | mriedem | finucannot: yeah i know it says that | |
| 13:07:55 | mriedem | finucannot: i know you want to land something, | |
| 13:08:15 | mriedem | but i also don't want to land a gaping hole that we don't fix for 4 years like the existing numa stuff | |
| 13:09:01 | mriedem | so what does the "claim" actually do? | |
| 13:09:05 | mriedem | since we won't have a claim during live migration | |
| 13:09:44 | finucannot | mriedem: The claim builds the guest's NUMA topology | |
| 13:09:56 | finucannot | For that to happen, I need to have information about the networks attached to the guest | |
| 13:10:14 | finucannot | Far as I can see, for a new instance the info cache is not yet populated | |
| 13:11:04 | finucannot | finucannot: Agreed on not having a gaping hole. The approach artom takes for solving live migration for NUMA should get us this almost for free, I'm guessing | |
| 13:11:14 | finucannot | *mriedem: | |
| 13:11:35 | artom | Passing IntanceNUMATopology as part of live_migrate_data? | |
| 13:11:55 | mriedem | finucannot: so this spec depends on artom's bp for live migration then? | |
| 13:12:51 | finucannot | mriedem: Kind of but not really | |
| 13:13:04 | mriedem | so you guys might want to talk about this.... | |
| 13:13:10 | finucannot | It needs that spec for live migration to work, but so does everything that involves NUMA and CPU pinning | |
| 13:13:11 | mriedem | i'm not familiar enough with artom's spec yet | |
| 13:13:18 | mriedem | right, ok, | |
| 13:13:26 | mriedem | so i think we call that out as a dependency for live migration to work, that's fine, | |
| 13:13:31 | finucannot | Seeing as they're currently very much tied, much to jaypipes chagrin | |
| 13:13:33 | mriedem | the rest could go ahead with that caveat | |
| 13:13:52 | finucannot | ack | |
| 13:15:13 | giblet | finucannot, mriedem: very similar thing will happen with the bandwidth. We need to regenerate the bandwidth request part of the request spec for all the VM move operations | |
| 13:16:24 | mriedem | giblet: yup, i think that was called out in your spec | |
| 13:16:32 | mriedem | finucannot: ok so i left some targeted things to update in your spec, then i think i'm +2 | |
| 13:16:48 | mriedem | i just want to make sure it's written down because it's a lot of churn and w/o the list of work items we're likely to forget something | |
| 13:16:58 | finucannot | Yup, that's fair | |
| 13:17:04 | giblet | mriedem: yes, it was | |
| 13:17:26 | mriedem | giblet: hopefully the internal churn doesn't negatively impact you | |
| 13:17:37 | giblet | mriedem: and now have some TODOs in the currently proposed patches where to do those. I.e. https://review.openstack.org/#/c/567268/9/nova/compute/api.py@4234 | |
| 13:18:08 | giblet | mriedem: there will be nice rebases I'm sure. But that is life :) | |
| 13:18:12 | mriedem | giblet: request spec tinkering should happen in conductor | |
| 13:18:35 | giblet | mriedem: OK, then 'badly placed TODOs' :) I can push those up in the call chain | |
| 13:18:46 | leakypipes | finucannot: well remembered. | |
| 13:23:00 | giblet | mriedem: thanks for the comments in that bwm patch about my TODOs. Thanks for the pointer like 'reset_request_destinations' | |
| 13:23:34 | mriedem | giblet: i might have gotten that method name wrong | |
| 13:23:57 | giblet | mriedem: I can apply AI to find the right one :) | |
| 13:23:59 | mriedem | reset_forced_destinations | |
| 13:24:05 | giblet | mriedem: ty | |
| 13:24:06 | mriedem | ha | |
| 13:24:11 | mriedem | is that your new job now? AI master? | |
| 13:24:28 | mriedem | train the machine to write your bw-aware series | |
| 13:24:37 | giblet | mriedem: it is more like a wanabe hobby | |
| 13:24:48 | mriedem | well at least you have a hobby | |
| 13:24:50 | giblet | mriedem: but it would be so easy just to push it to an AI | |
| 13:25:25 | bauzas | warning, I'm changing my Friday nick | |
| 13:25:58 | PapaOurs | leakypipes: thanks for having reviewed https://review.openstack.org/#/c/557065/ | |
| 13:26:50 | PapaOurs | leakypipes: as far as I understand, your strong -1 is related to the fact it's about traits and nvidia | |
| 13:27:06 | PapaOurs | leakypipes: but look at https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide#51-check-mdev-module-kvmgt-only | |
| 13:27:37 | PapaOurs | leakypipes: mdev's supported_types is a kernel's VFIO feature | |
| 13:27:52 | sususuryashines | hansmoleman: you finally got your friday nick!? :D | |
| 13:27:53 | PapaOurs | leakypipes: so even if only nvidia uses it, why the spec should be about nvidia ? | |
| 13:31:59 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec https://review.openstack.org/541290 | |
| 13:33:53 | fried_rice | What's ironic's nova CI called? | |
| 13:34:48 | leakypipes | PapaOurs: that mdev_supported_types is nothing more than a reference to NVIDIA's product names. | |
| 13:34:53 | sususuryashines | dansmith, hansmoleman: would like your opinion on https://review.openstack.org/#/c/560042/ whenever you have the time. | |
| 13:35:18 | dansmith | this sounds like a job for... | |
| 13:35:46 | jroll | fried_rice: something-ironic-something :P | |
| 13:36:02 | jroll | ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa | |
| 13:36:08 | fried_rice | oh, there it is. | |
| 13:36:11 | fried_rice | thanks jroll | |
| 13:36:15 | jroll | np | |
| 13:36:24 | MurderTheLeafBlo | damn restrictions on nick length. | |
| 13:36:31 | jroll | heh | |
| 13:37:12 | fried_rice | leakypipes: DieLeafBlowerDie ought to fit | |
| 13:37:53 | leakypipes | fried_rice: oooh, nice. | |
| 13:40:47 | hansmoleman | sususuryashines: only temporary | |
| 13:40:56 | hansmoleman | i'm actually allergic to fun | |
| 13:40:59 | openstackgerrit | Tsuyoshi Nagata proposed openstack/nova master: nova improvement of maximum attach volumes more than 26 vols https://review.openstack.org/567472 | |
| 13:41:42 | sususuryashines | hansmoleman: :P | |
| 13:42:54 | hansmoleman | finucannot: thanks, +2 | |
| 13:43:06 | hansmoleman | superdan: +2 on finucannot's numa-aware vswitch spec now https://review.openstack.org/#/c/541290/ | |
| 13:43:33 | finucannot | hansmoleman: Thanks, appreciate it | |
| 13:45:24 | PapaOurs | leakypipes: "you make sure the "mdev_supported_types" node with differenct vgpu type existed(The "V#ID" represent the corresponding platform, "V4" means it is "Broadwell" platform, "V5" means it is "Skylake" or "Kabylake" platform)" | |
| 13:45:55 | PapaOurs | leakypipes: unless I'm misunderstanding the above, but it's related to an Intel thing, right? | |
| 13:46:51 | PapaOurs | leakypipes: and yet again, it's a VFIO abstraction | |
| 13:47:09 | PapaOurs | leakypipes: why should we call it 'nvidia' even if the nvidia folks provided it ? | |
| 13:47:30 | PapaOurs | it's like if we would say that a libvirt feature supported by the Nova API is only a 'libvirt' one | |
| 13:47:58 | PapaOurs | it could be a Xen or VMWare feature if the virt driver supports it | |
| 13:48:04 | leakypipes | PapaOurs: they *are* the libvirt ones. | |
| 13:49:09 | leakypipes | PapaOurs: I'm not saying we should be leaking vendor details out of the user-facing API. I'm just saying when referring to "vGPU types", we should be honest about it and say what we mean, which is "the NVIDIA vendor model for this NVIDIA pGPU". | |
| 13:49:13 | hansmoleman | is cdent out this week? | |
| 13:49:37 | leakypipes | hansmoleman: I'm not sure. I've seen him on ML off and on. not much on IRC. | |
| 13:49:57 | figleaf | hansmoleman: he's at the vmware mother ship, so I'm sure his attention is spread thin | |
| 13:50:32 | hansmoleman | ah ok | |
| 13:50:47 | hansmoleman | gonna setup a 100 node fake devstack env for some scheduler perf testing, i knew he did something like this before | |
| 13:51:02 | leakypipes | PapaOurs: btw, where is Bauwser? :) | |
| 13:51:22 | leakypipes | hansmoleman: placecat. | |
| 13:51:44 | hansmoleman | i don't need to test placement | |
| 13:51:48 | leakypipes | hansmoleman: https://github.com/cdent/placecat/ maybe what you were thinking? | |
| 13:51:50 | fried_rice | hansmoleman: He has some fairly detailed step-by-step on his blog. Let me know if you want me to dig that up. | |
| 13:52:17 | hansmoleman | fried_rice: yeah i've seen that one before, i think i've got this, it's basically (1) fake virt driver (2) noop quota and (3) NUMBER_FAKE_NOVA_COMPUTE=x | |
| 13:52:34 | hansmoleman | i'm going to try and test before and after https://review.openstack.org/#/c/569247/ | |
| 13:52:45 | hansmoleman | with 100 nodes, 1000 instances, 10 per node | |
| 13:53:08 | PapaOurs | leakypipes: but again, looks like Intel have multiple types, where each of them about an Intel platform | |
| 13:53:30 | leakypipes | PapaOurs: show me. everything I see in their docs refers to NVIDIA vGPU types. | |
| 13:53:37 | superdan | hansmoleman: finucannot I still have questions in there, maybe hansmoleman can clear it up for me if he gets it and I'm just slow | |