| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-28 | |||
| 14:51:05 | jianghuaw_ | Per my understand, the display heads will always be consumed automatically as long as the VGPUs supporting display heads. | |
| 14:53:11 | jianghuaw_ | Actually different vGPU types may support different display heads. And users may need some vGPUs which support specified amount of display heads. That's why I said it seems somehow traits for the vGPUs. | |
| 14:54:00 | efried | jianghuaw_ Yes, that sounds like it might be suitable for traits. | |
| 14:55:00 | jianghuaw_ | efried, but jaypipes seems don't agree ^ :-) | |
| 14:55:24 | bauzas | jianghuaw_: well, requesting a display head is not quantitative | |
| 14:55:35 | efried | jianghuaw_ It depends whether it can be consumed independently, or is always tied to the VGPU. | |
| 14:55:43 | efried | Which I'm still not clear on. | |
| 14:56:24 | jianghuaw_ | efried, yes, it's always tied to VGPU. | |
| 14:56:35 | efried | Okay. If it is *always* the case that requesting a specific VGPU results in a specific number (possibly zero) of display heads being consumed, then there's no reason to inventory separately. | |
| 14:57:55 | efried | jianghuaw_ And how does the user specify which type of VGPU they're getting? | |
| 14:58:02 | bauzas | by the trait | |
| 14:58:15 | jianghuaw_ | yes, by traits. | |
| 14:58:18 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Nits from Ic3ab7d60e4ac12b767fe70bef97b327545a86e74 https://review.openstack.org/523432 | |
| 14:58:30 | bauzas | given we don't support traits yet, we only ask for the operator to provide *one* type | |
| 14:58:47 | efried | So a given trait is in fact overloading more than one aspect of the VGPU's characteristics. | |
| 14:59:15 | bauzas | well | |
| 14:59:22 | efried | In other words, by saying I need a VGPU of type X, I'm also implicitly stating that I'm going to get two display heads (or whatever) | |
| 14:59:33 | bauzas | that is a correct assumption to me | |
| 14:59:59 | efried | Okay. Then if that correlation always holds true | |
| 15:00:12 | efried | that is, a given VGPU type always maps to a given number of display heads | |
| 15:00:21 | jianghuaw_ | the plan is to associate traits like display_solutions; supported features after we support traits. | |
| 15:00:26 | bauzas | efried: see the spec | |
| 15:00:33 | bauzas | there are some examples | |
| 15:00:40 | efried | then you shouldn't have inventory for the display heads. | |
| 15:00:45 | bauzas | I agree | |
| 15:00:52 | bauzas | if that's correlated | |
| 15:01:10 | efried | And there's even no need for extra traits - though those could be included and it wouldn't hurt anything. | |
| 15:01:12 | bauzas | tbh, I haven't thought that much on that problem, since libvirt doesn't return the heads :p | |
| 15:01:20 | bauzas | (yet) | |
| 15:02:00 | jianghuaw_ | efried, the display heads is one factor can be used to determine a vGPU type. | |
| 15:02:26 | efried | jianghuaw_ Ah, okay, if you want to be able to go in the other direction, then it makes sense. | |
| 15:03:10 | efried | jianghuaw_ I can imagine that you don't want to be getting particular about VGPU types; rather, you want to be enumerating capabilities of each type, so that the scheduler could conceivably pick one of any number of types as long as they fit the capabilities you request. | |
| 15:03:15 | mriedem | gibi: replied in https://review.openstack.org/#/c/523353/ and explained the issue | |
| 15:03:24 | jianghuaw_ | But the possible value is a continuous number which makes it more like quantitative. | |
| 15:03:58 | gibi | mriedem: looking | |
| 15:04:07 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/newton: Refined fix for validating image on rebuild https://review.openstack.org/523434 | |
| 15:04:54 | mriedem | instance actions/events are mythical beasts | |
| 15:04:57 | mriedem | easily broken | |
| 15:05:02 | mriedem | rarely tested | |
| 15:05:19 | jianghuaw_ | efried, yes. That's also the result of the discussion with jaypipes to use capabilities instead of specifying vGPU type. | |
| 15:05:27 | efried | jianghuaw_ But a small number of discrete possible values | |
| 15:05:29 | mriedem | dansmith: i've got those backports all up now https://review.openstack.org/#/q/I1a46ef1503be2febcd20f4594f44344d05525446 | |
| 15:05:39 | efried | jianghuaw_ Like 1, 2, 4, 8 | |
| 15:05:39 | jianghuaw_ | efried, indeed. | |
| 15:05:45 | gibi | mriedem: thanks, I | |
| 15:05:49 | gibi | mriedem: thanks, I'm +2 now | |
| 15:06:09 | jianghuaw_ | efried, it looks like you agree with me to make it as traits. right? | |
| 15:06:52 | efried | jianghuaw_ With the caveat that I don't fully understand the different ways you can request/configure these things, yes, I believe I agree. | |
| 15:07:26 | mriedem | sdague: could use some review on https://review.openstack.org/#/c/521391/ which is a fix for a regression introduced by a recent cve fix, so it's going to have to be backported through to newton - there is a regression test patch underneath it | |
| 15:07:36 | openstackgerrit | jiangpf proposed openstack/nova master: Encode libvirt domain XML in UTF-8 https://review.openstack.org/522161 | |
| 15:07:45 | efried | jianghuaw_ A given VGPU type will only ever have *one* of the traits (e.g. SINGLE_DISPLAY_HEAD_CAPABLE, DUAL_DISPLAY_HEAD_CAPABLE, QUAD_DISPLAY_HEAD_CAPABLE) right? | |
| 15:08:37 | mriedem | sdague: actually that regression test might be busted now, checking | |
| 15:08:58 | jianghuaw_ | efried, at the moment I see the possible number is 1, 2, 4, 8 | |
| 15:09:38 | efried | jianghuaw_ Okay; the question remains: a given VGPU type will *always* and *only* consume *one* of those numbers of display heads? | |
| 15:10:18 | jianghuaw_ | correct. | |
| 15:10:47 | efried | Then yes, I think it's appropriate *not* to inventory display heads separately, and I think it's okay to have those be traits. | |
| 15:11:18 | dansmith | mriedem: ack | |
| 15:11:19 | efried | Now if I want a VGPU with four display heads, I request resources=VGPU:1&required=QUAD_DISPLAY_HEAD_CAPABLE | |
| 15:11:57 | jianghuaw_ | efried, yeah. That's what I was thinking:-) | |
| 15:12:04 | efried | jaypipes Does this seem sane to you ^^ | |
| 15:12:22 | jaypipes | gimme a minute, folks. trying to finish rebasing n-r-p | |
| 15:13:14 | jaypipes | ok, final tests running now... lemme read back, sorry | |
| 15:13:32 | efried | jaypipes Summary: A given VGPU type will *always* have a certain number of display heads. So display heads as traits (SINGLE_DISPLAY_HEAD_CAPABLE, DUAL_DISPLAY_HEAD_CAPABLE, etc.) and a RP of VGPUs (presumably the pGPU) would only ever have one of those traits. | |
| 15:13:55 | jianghuaw_ | efried, thanks for the summary. | |
| 15:14:34 | jaypipes | efried: if the display head is *consumed* by a request, it needs to be a resource class, not a trait. | |
| 15:15:17 | efried | jaypipes The issue is that the number of display heads are always correlated exactly with the VGPU type. | |
| 15:15:47 | jianghuaw_ | jaypipes, the display heads will always be consumed automatically when requesting VGPU. | |
| 15:15:58 | jaypipes | efried: I don't see any issue with that. (plus, I guarantee you nvidia and intel will end up changing that in the future. it's what they do. ALL THE TIME. | |
| 15:16:06 | alex_xu | mriedem: yea, you are right, without 'migrate' key, it won't route to that action | |
| 15:16:13 | bauzas | jaypipes: the problem here is that display heads are correlated by the number of VGPUs and their types | |
| 15:16:26 | bauzas | oh man | |
| 15:16:27 | jaypipes | bauzas: I don't see a problem? | |
| 15:16:47 | jaypipes | bauzas: set the amount of VGPU and display head resources in the flavor correctly, no? | |
| 15:16:59 | bauzas | jaypipes: once we have traits, it's doable | |
| 15:17:11 | jaypipes | bauzas: traits have nothing to do with this. | |
| 15:17:22 | bauzas | jaypipes: for the moment, the user has no clue about which type he will get | |
| 15:17:31 | alex_xu | efried: you mean you are working on the two testcases in this patch https://review.openstack.org/498737 ? | |
| 15:17:34 | bauzas | hence how many heads he could get | |
| 15:17:36 | efried | alex_xu Yes | |
| 15:17:41 | jaypipes | bauzas: it's not the user. it's the deployer/admin that needs to set shit up. | |
| 15:17:42 | alex_xu | efried: cool, thanks | |
| 15:17:51 | efried | alex_xu The first one is ported over, and passing. Working on the second one... | |
| 15:17:56 | bauzas | jaypipes: I don't disagree | |
| 15:18:15 | bauzas | jaypipes: the operator provides which supported types the compute should provide | |
| 15:18:26 | bauzas | so the VGPUs will depend on thaty | |
| 15:18:29 | bauzas | and the heads | |
| 15:18:54 | alex_xu | efried: I ported the first one on Monday, but interupt by other works... so nvm, thanks for porting those | |
| 15:19:01 | bauzas | but then, if the user wants a specific GRID-K5000, then the operator will set the flavor with a trait | |
| 15:19:41 | jaypipes | bauzas: correct. if the virt driver (Xen, libvirt, whatevs) wants to do some fancy-pants discovery on startup of nova-compute and ensure that inventory counts are proper for the types of GPUs found on the host, cool with me. But it's the deployer's responsibility to create flavors that make sense for these related resources. | |
| 15:19:44 | bauzas | anyway, I need to go | |
| 15:19:58 | bauzas | disappearing for 20 mins | |
| 15:20:01 | bauzas | -ish | |
| 15:20:25 | jianghuaw_ | jaypipes, as the display heads are optional (we have to allow that as the vGPU may not support display heads). If the flavor has resources=VGPU:1; then placement may return resource providers which have display heads. In that case, the display heads are consumed automatically. | |
| 15:20:33 | jianghuaw_ | That's the problem. | |
| 15:20:44 | bauzas | jaypipes: one last thing, libvirt doesn't support display heads yet | |
| 15:20:45 | bauzas | :p | |
| 15:20:49 | efried | jaypipes Here's the counterexample: One pGPU provides VGPU types that always allocate four display heads, so it exposes inventory of VGPU:2,DISPLAY_HEAD:8. Some other pGPU always allocates two display heads, so it exposes inventory of VGPU:2,DISPLAY_HEAD:4. In my flavor, I request VGPU:1,DISPLAY_HEAD:2. Scheduler happily schedules me to that first one, and allocates usage of 2 display heads. But we actually consume four. | |
| 15:20:53 | bauzas | (so I'm not fully on track with that) | |
| 15:20:55 | jaypipes | jianghuaw_: no, nothing should be "consumed automatically". that's the problem. :) | |
| 15:21:18 | dansmith | mriedem: are you not going to +2 this? https://review.openstack.org/#/c/521662/ | |