Posted	Nick	Remark
#openstack-nova - 2018-03-23
10:15:12	bauwser	because I was thinking of one child RP being the PCI device
10:15:25	bauwser	but then, depending on the GPU type, you could have different inventories
10:15:46	bauwser	so it would be yet another tree level, with each type being a child ?
10:18:07	bauwser	jianghuaw_: nothing in the spec mentions what if we have multiple types per pGPU https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/add-support-for-vgpu.html
10:18:23	kashyap	dansmith: melwitt: And yes, restricting the backport to one option with the _same_ config attribute sounds list a reasonable compromise
10:18:32	kashyap	(As to the rest of the questions, answering on the review.)
10:18:47	openstackgerrit	jichenjc proposed openstack/nova master: z/VM Driver: Initial change set of z/VM driver https://review.openstack.org/523387
10:18:48	openstackgerrit	jichenjc proposed openstack/nova master: z/VM Driver: add snapshot function https://review.openstack.org/534240
10:18:48	openstackgerrit	jichenjc proposed openstack/nova master: z/VM Driver: Spawn and destroy function of z/VM driver https://review.openstack.org/527658
10:18:49	openstackgerrit	jichenjc proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344
10:18:49	openstackgerrit	jichenjc proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340
10:19:03	bauwser	jianghuaw_: that said, nvidia says that it can only support one type per pGPU in http://docs.nvidia.com/grid/latest/grid-vgpu-user-guide/index.html#homogeneous-grid-vgpus
10:19:11	bauwser	so I wonder if that really matteres
10:27:13	openstackgerrit	Huang Rui proposed openstack/nova master: z/VM Driver: add snapshot function https://review.openstack.org/534240
10:27:15	openstackgerrit	Huang Rui proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340
10:27:16	openstackgerrit	Huang Rui proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344
10:31:09	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: RP delete inventories (v1.5) https://review.openstack.org/514642
10:31:11	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644
10:31:11	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: CLI for traits (v1.6) https://review.openstack.org/514643
10:31:12	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647
10:31:12	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646
10:31:13	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: Transactionally update allocations (v1.13) https://review.openstack.org/546674
10:31:13	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: New dict format of allocations (v1.11, v1.12) https://review.openstack.org/542819
10:31:14	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: Limit allocation candidates (v1.15, v1.16) https://review.openstack.org/548043
10:31:14	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675
10:31:15	openstackgerrit	Andrey Volkov proposed openstack/osc-placement master: Allocation candidates parameter: required (v1.17) https://review.openstack.org/548326
10:35:45	kashyap	sean-k-mooney: Thanks for the comment here: https://review.openstack.org/#/c/534384/10/nova/virt/libvirt/driver.py
10:37:24	openstackgerrit	Merged openstack/nova master: Not use thread alloc policy for emulator thread https://review.openstack.org/538700
10:51:57	kashyap	dansmith: melwitt: While I understand the backport stance. FWIW, talking to danpb (who is SME on this topic) on IRC, he still thinks it's an artificial limiting for the sake of backports.
10:52:27	kashyap	I feel that we're over-evaluating. But whatever.
11:04:03	openstackgerrit	Yikun Jiang (Kero) proposed openstack/nova-specs master: Complex (Anti)-Affinity Policies https://review.openstack.org/546925
11:06:11	openstackgerrit	sahid proposed openstack/nova-specs master: virt: allow instances to be booted with trusted VFs https://review.openstack.org/485522
11:47:19	sahid	jaypipes: i think we are good with the trusted vfs spec: can you have a final look? https://review.openstack.org/#/c/485522/
12:09:19	openstackgerrit	Chris Dent proposed openstack/nova master: Use microversion parse 0.2.1 https://review.openstack.org/550265
12:29:11	fried_rice	Gate fixed? Time to recheck-all?
12:41:22	openstackgerrit	Stephen Finucane proposed openstack/nova master: Stop using mox in virt/xenapi/image/test_vdi_through_dev.py https://review.openstack.org/342682
12:41:43	fried_rice	eric-young: I don't see the os-brick release proposed yet. Need help?
12:47:16	eric-young	fried_rice, there was some talk yesterday in the cinder channel about needing one more patch merged first. was going to check on status here in a bit
12:47:34	fried_rice	eric-young: Roger that, just checking in :)
12:48:17	fried_rice	(I'm in no hurry, just saw the nova patch go by again this morning)
12:49:24	eric-young	fried_rice, I am in no super hurry either but it'd be good to get that patch off my plate :)
12:50:49	eric-young	also need to get zuul to approve it. seeing an error with tempest-full-py3 on POST_FAILURE
13:01:43	leakypipes	sususuryashines: welcome to Friday :)
13:02:38	kashyap	leakypipes: You've got one hell of a plumbing expenses there :P
13:02:46	kashyap	s/expenses/bill/
13:03:01	sususuryashines	leakypipes : hehe, thanks!
13:03:22	leakypipes	kashyap: indeed.
13:07:02	fried_rice	eric-young: That one should be recheckable now.
13:12:37	eric-young	thanks, will do
13:19:29	sq4ind	hey guys, any way to recover VM which has been lost during live migration ? I cannot find it on any hypervisor
13:19:39	sq4ind	tried this already: https://docs.openstack.org/nova/latest/admin/node-down.html
13:19:46	sq4ind	no luck ;/
13:23:35	openstackgerrit	Merged openstack/nova-specs master: virt: allow instances to be booted with trusted VFs https://review.openstack.org/485522
13:27:48	openstackgerrit	Patricia Domingues proposed openstack/nova master: load up the volume drivers by checking architecture https://review.openstack.org/541393
13:34:28	dansmith	johnthetubaguy: https://review.openstack.org/#/c/539605
13:38:24	giblet	fried_rice, leakypipes: when placement was designed was it intentionaly decided that placement does not provide information about which part of an allocation candidate fulfills which part of the request?
13:39:22	fried_rice	giblet: That seems like it would be a tough thing to design, implement, reason about.
13:39:23	giblet	fried_rice, leakypipes: I'm hit the issue that Neutron needs to know which part of an allocation record fulfills the original resource request of a given port
13:39:35	bauwser	fried_rice: leakypipes: I have a question for you about https://review.openstack.org/#/c/552924/
13:39:36	leakypipes	giblet: not sure I follow you... an allocation request does indeed indicate which resources are served by which providers...
13:40:19	fried_rice	giblet: Ah, yes, that's legitimate, and an issue that virt drivers will also have. It's going to come down to neutron needing to be able to map RP IDs/names to something that lets it know which real resource it corresponds to.
13:40:48	bauwser	fried_rice: leakypipes: if we split the compute resources in between NUMA nodes (like for vCPUs), if a guest is asking for 2 vCPUs, would it be possible to have one vCPU in one NUMA node and the other vCPU in a separate node ?
13:41:01	bauwser	like we do at the moment?
13:41:12	fried_rice	bauwser: only if you specify them in separate request groups.
13:41:28	bauwser	fried_rice: that's my concern
13:41:47	giblet	leakypipes: true, the allocation request is created against an RP, but the connection between an allocation request and the original resource request of a port is missing
13:41:56	fried_rice	bauwser: ...or if the driver models them in a single RP. I.e. the host is set up not to do NUMA at all.
13:42:08	bauwser	fried_rice: leakypipes: for the moment, say I have two NUMA nodes with 4 pCPUs each one
13:42:17	leakypipes	giblet: I'm not following you...
13:42:37	fried_rice	giblet: I think what we're getting at is: if you're having trouble making that connection, it's because you didn't split up your RPs enough.
13:43:04	bauwser	fried_rice: leakypipes: if 3 pCPUs are already taken, I can still have a instance using two pCPUs from two different NUMA nodes
13:43:28	bauwser	fried_rice: leakypipes: if we say we need to have a request query for that, then it would be a problem
13:43:33	giblet	fried_rice: OK that is a direction I have to investigate in the neutron port case
13:44:06	giblet	leakypipes: there is a neturon port, that will have a resource_request, that will end up as a granular resource request group in the GET allocation_candidates query
13:44:42	giblet	leakypipes: but parts of the returned allocation candidates does not mapps back to the original granular resource request group
13:45:21	giblet	leakypipes: I means placement does not specify which subset of an allocation candidate maps to a certain granular resource group
13:45:46	fried_rice	giblet: That's correct, but it also shouldn't need to.
13:45:51	openstackgerrit	Bence Romsics proposed openstack/osc-placement master: RP delete inventories (v1.5) https://review.openstack.org/514642
13:45:51	openstackgerrit	Bence Romsics proposed openstack/osc-placement master: RP list: member_of and resources parameters (v1.3, v1.4) https://review.openstack.org/511183
13:45:52	openstackgerrit	Bence Romsics proposed openstack/osc-placement master: CLI for traits (v1.6) https://review.openstack.org/514643
13:45:53	openstackgerrit	Bence Romsics proposed openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644
13:45:54	openstackgerrit	Bence Romsics proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647
13:45:54	openstackgerrit	Bence Romsics proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646
13:45:55	openstackgerrit	Bence Romsics proposed openstack/osc-placement master: New dict format of allocations (v1.11, v1.12) https://review.openstack.org/542819
13:45:55	openstackgerrit	Bence Romsics proposed openstack/osc-placement master: Transactionally update allocations (v1.13) https://review.openstack.org/546674
13:45:56	openstackgerrit	Bence Romsics proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675
13:45:57	openstackgerrit	Bence Romsics proposed openstack/osc-placement master: Limit allocation candidates (v1.15, v1.16) https://review.openstack.org/548043
13:45:57	openstackgerrit	Bence Romsics proposed openstack/osc-placement master: Allocation candidates parameter: required (v1.17) https://review.openstack.org/548326
13:46:39	fried_rice	giblet: Because if you have two request groups that otherwise look the same, then it shouldn't matter which of those two pieces of the response you "use" for which.
13:46:45	kashyap	superdan: BTW, thanks for the validation question, that prompted me to file the bug that I needed to, for the new libvirt API: https://review.openstack.org/#/c/534384/10/nova/conf/libvirt.py
13:46:52	giblet	leakypipes, fried_rice: port1 and port2 both needs BW resource, an allocation candidate will have RP - BW pairs for both port1 and port2 but there is no way to tell which pair maps to which port
13:46:56	kashyap	superdan: And the libvirt dev already assigned it to himself and working on it :-)
13:47:07	fried_rice	But if the request groups were differentiated by, say, a custom trait indicating a physical network, then those traits will be in the provider summary, and you can use that to distinguish.
13:47:07	superdan	kashyap: cool
13:47:32	kashyap	superdan: Appreciate the eagle eyes.
13:47:40	giblet	fried_rice: true, the response is not ambigous. It is just haaard to make a generic code that does the mapping
13:47:46	leakypipes	giblet: the provider_summaries section of the allocation candidates response contains all the trait and usage information that callers would need to decide that mapping, though.
13:47:49	fried_rice	giblet: Well, you'd have to do the math, yeah.
13:48:05	fried_rice	which I agree is awkward
13:48:14	giblet	leakypipes, fried_rice: thanks, I understand now

Earlier   Later