| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-28 | |||
| 14:43:27 | mdbooth | Or whatever hopefully much better boot solution is in Power :) | |
| 14:43:43 | efried | mdbooth That's exactly the point: The boot list is specified based on hardware addresses, which are discovered based on slots. | |
| 14:45:04 | efried | mdbooth The big conceptual divide here is that PowerVM has a real hypervisor and the guests are real partitions. | |
| 14:46:10 | jianghuaw_ | bauzas, I think efried's opinion is that we shouldn't make inventory for VGPU_DISPLAY_HEAD as that's possible to be consumed automatically by requesting VGPU. | |
| 14:46:54 | efried | jianghuaw_ Only if display heads are *only* consumed automatically by requesting VGPU | |
| 14:47:29 | edleafe | jianghuaw_: if it can't be consumed independently, and is always consumed automatically, then it shouldn't be tracked as inventory. | |
| 14:47:45 | efried | jianghuaw_ If it's possible to request them separately, then you need to inventory them separately; and then have extra logic in scenarios where it would happen automatically such that, if the flavor doesn't request the appropriate number of each, you throw an error. | |
| 14:47:46 | bauzas | jianghuaw_: I agree with him | |
| 14:48:18 | bauzas | jianghuaw_: until we have a way to track optional resources classes, we shouldn't be providing inventories for display heads IMHO | |
| 14:48:42 | bauzas | and just do the display head consumption solely in the virt driver, if you can | |
| 14:48:59 | bauzas | tbh, libvirt doesn't support that yet, so I don't give a bit of that :p | |
| 14:49:10 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Refined fix for validating image on rebuild https://review.openstack.org/523427 | |
| 14:50:14 | jianghuaw_ | bauzas, efried Ok. Agreed. I will drop that patch for inventoring display heads. | |
| 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 | |