| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-12 | |||
| 14:48:29 | gibi | yes | |
| 14:48:50 | bauzas | so how can I get the RP ? | |
| 14:49:01 | bauzas | I just have the RP UUID | |
| 14:49:02 | efried | the rp is in there, but only its uuid, not its name. | |
| 14:49:10 | gibi | ok it is just the UUID | |
| 14:49:22 | gibi | what else you would need? then name ? | |
| 14:49:25 | efried | I thought we made a convention for setting the RP UUID based on some aspect of the VGPU | |
| 14:49:31 | gibi | what connects an RP and an mdev? | |
| 14:49:33 | efried | gibi: he needs to be able to associate the RP with the PGPU | |
| 14:49:46 | efried | which he can do from the name for sure, because we used some kind of naming convention. | |
| 14:49:53 | gibi | efried: I see | |
| 14:50:01 | efried | but with just the uuid, unless we named the rp somehow after the uuid of the pgpu, we're fooked. | |
| 14:50:06 | gibi | efried: that is a problem as the provider summaries are not send down | |
| 14:50:16 | efried | Is the name in the provider summary? | |
| 14:50:25 | gibi | hm | |
| 14:50:27 | gibi | looking | |
| 14:50:57 | efried | doesn't look like it. | |
| 14:51:38 | TheJulia | jroll: That looks awesome. Thanks! | |
| 14:52:34 | efried | bauzas: So unless we did in fact make some special way of assigning the RP UUID based on the identity of the pgpu, you're going to need to store that mapping locally somehow, which is ew. | |
| 14:52:50 | gibi | efried: you are right | |
| 14:53:46 | bauzas | efried: yeah it's a problem | |
| 14:53:54 | efried | you can store an instance variable in the virt driver from update_provider_tree, with a big TODO on it to figure out a better way. | |
| 14:54:00 | bauzas | we only have a convention for the name, not the uuid | |
| 14:54:02 | efried | And I'm wrong, it has nothing to do with gibi's spec | |
| 14:54:03 | jroll | TheJulia: cool, I'll un-wip. thanks | |
| 14:54:12 | efried | jroll: I'll bump my vote | |
| 14:54:29 | jroll | efried: thanks | |
| 14:54:57 | bauzas | efried: okay, I guess we have a big problem honestly | |
| 14:55:06 | bauzas | because I don't want to do this like that | |
| 14:55:23 | bauzas | if we want to select a node, then we need to know which one | |
| 14:55:25 | efried | um, maybe I'm wrong about being wrong. But it gives us something extra to think about in gibi's spec, which is that we have to have the information in the allocation itself, OR figure out some other way to get that info into spawn. | |
| 14:55:42 | gibi | efried: yeah, it is not the spec you linked, but I had similar issue to map pci device to RP, there it is done by the RP name, and there is an extra call in the compute/manager to get the RP name | |
| 14:55:43 | efried | but I think the libvirt problem is an extra one. | |
| 14:56:07 | efried | Perhaps we should consider amending the allocation structure to include the rp name. | |
| 14:56:16 | bauzas | so, again, I'll say we're blocked | |
| 14:56:40 | bauzas | unless the virt driver calls placement to know the RP tree | |
| 14:56:41 | efried | jaypipes: backscroll to :42:21 | |
| 14:56:53 | cdent | i'd be pretty opposed to include the name of the rp in the allocation unless we really can't come up with something | |
| 14:56:54 | efried | bauzas: Yes, that would be another "solution" that would be ew. | |
| 14:56:59 | cdent | why _not_ pass the summaries? | |
| 14:57:16 | cdent | or why not let the virt driver talk to placement? | |
| 14:57:18 | NewBruce | sean-k-mooney : back | |
| 14:57:26 | cdent | or any of several other options | |
| 14:57:34 | bauzas | I'll upload my change anyway | |
| 14:57:35 | efried | cdent: not pass the summaries because a) way too much information, unless we pare it down to just the summaries in the allocation, and b) the name isn't in the summaries anyway :P | |
| 14:58:07 | cdent | b) right, but putting it in the summaries would make some form of sense: it's a provider _summary_ after all | |
| 14:58:09 | cdent | however | |
| 14:58:18 | cdent | using meaningful names is a really super dangerous territory | |
| 14:58:20 | gibi | bauzas, efried: this is the PCI - RP mapping solution I come up with https://review.openstack.org/#/c/623543/23/nova/compute/manager.py It works as the pci claim can match devices by abitrary tag | |
| 14:58:30 | efried | cdent: we need some way of mapping RP to "real thing". | |
| 14:58:42 | efried | I know: arbitrary metadata on resource_provider! | |
| 14:58:42 | cdent | which isn't placements job | |
| 14:59:00 | cdent | mapping rp to real thing is the either nova or the virt drivers job | |
| 14:59:19 | efried | gibi: Right, so you're storing the mapping locally in memory. | |
| 14:59:41 | gibi | efried: calculating the mapping by calling placement during boot | |
| 14:59:51 | gibi | efried: nothing stored between boots | |
| 14:59:52 | efried | cdent: Which is what I suggested initially as the workaround. I though it was ew, but I'm kind of coming around to the idea. | |
| 15:00:10 | efried | you don't need to store anything between boots; you construct the information in update_provider_tree in any case. | |
| 15:00:15 | efried | that's where you would save the mapping. | |
| 15:00:22 | efried | you can't spawn untile you've update_provider_treeD | |
| 15:00:25 | bauzas | gibi: you're calling placement to get the RP name, right? | |
| 15:00:33 | gibi | bauzas: yes | |
| 15:00:47 | efried | Could pass the provider_tree into spawn. That would let you look up the name. | |
| 15:00:49 | gibi | bauzas: https://review.openstack.org/#/c/623543/23/nova/compute/manager.py@2138 | |
| 15:01:15 | bauzas | gibi: yeah that's what I saw | |
| 15:01:28 | bauzas | it wasn't a question actually, more a clarification :) | |
| 15:01:36 | bauzas | gibi: but here I'm working on the driver side | |
| 15:01:46 | bauzas | I'm not sure I have the report client | |
| 15:01:54 | efried | would have to be a read-only/copy of the provider tree. | |
| 15:01:55 | gibi | bauzas: I know, you have to pass some extra info to the driver anyhow | |
| 15:01:55 | bauzas | and I think we basically said no | |
| 15:02:16 | bauzas | I mean, we agreed on not having the virt driver calling placement for various reasons | |
| 15:02:26 | efried | yeah | |
| 15:02:31 | openstackgerrit | Boris Bobrov proposed openstack/nova master: Add configs for AMD SEV https://review.openstack.org/636318 | |
| 15:02:41 | bauzas | so, I'm stuck with finding a way to pass down the providertree structure down the wire | |
| 15:02:55 | efried | bauzas: You have the provider tree in the compute manager. | |
| 15:02:59 | bauzas | just because I want to know which physical resource is there | |
| 15:03:13 | efried | no need to make calls to placement. | |
| 15:03:18 | kashyap | time git fetch gerrit | |
| 15:03:31 | bauzas | efried: correct, I could amend https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3106 | |
| 15:04:08 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: [WIP] libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION for "Stein" https://review.openstack.org/632507 | |
| 15:04:09 | efried | bauzas: Right. Add provider_tree. Get it the same way we get it before update_provider_tree (i.e. make a copy of it). | |
| 15:04:39 | bauzas | there could be race conditions, right? | |
| 15:04:58 | efried | Not that wouldn't cause blowups anyway. | |
| 15:05:27 | efried | E.g. if I remove the pgpu rp between allocating and spawning, I'm effed in any case. | |
| 15:06:37 | gibi | efried: but you cannot do that without removing the allocation as well, which breaks nova as that allocation is created by nova | |
| 15:07:07 | efried | gibi: Swhat I'm saying, I don't see how you could contrive a race condition that would make the provider_tree be out of sync with the allocations without already having broken something else in the process. | |
| 15:07:18 | gibi | efried: I agree | |
| 15:07:32 | efried | I mean, some other unrelated provider could be out of sync I suppose. But I would hope that wouldn't matter. | |
| 15:07:39 | bauzas | efried: to be honest, I don't care of allocations | |
| 15:07:45 | bauzas | efried: I only care of the RP tree | |
| 15:07:53 | efried | well, you need the allocation to determine the rp | |
| 15:08:01 | bauzas | it's already there, and I trust it | |
| 15:08:30 | efried | And if you have more than one vgpu allocated, you need to know that. | |
| 15:08:41 | bauzas | ideally, it'd be waaaaay better and cleaner if I was getting the RP structure from placement as part of the message it returns me | |
| 15:08:42 | efried | I assume/hope you're getting that information from the allocation and not from somewhere else. | |
| 15:08:56 | bauzas | because my cache could be stale | |
| 15:09:04 | efried | bauzas: But what do you mean by "structure"? | |
| 15:09:28 | efried | It doesn't help you simply to know that the provider of the vgpu resource is a "child". You will eventually have to know *which* child. | |
| 15:09:30 | bauzas | efried: the mdev allocation logic is made there https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6251 | |