| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 18:34:58 | mriedem | as long as allocation candidates handles NRP it's done isn't it? | |
| 18:35:05 | mriedem | https://blueprints.launchpad.net/nova/+spec/nested-resource-providers-allocation-candidates | |
| 18:35:41 | mriedem | and https://blueprints.launchpad.net/nova/+spec/placement-return-all-resources i guess | |
| 18:36:55 | efried | melwitt: In the sense that reshaper (which is a bp) is part of nrp, we're not done with nrp yet. There's also client-side work to be done on nrp that we haven't really even figured out the scope of. | |
| 18:37:24 | efried | But yes, besides reshaper, the actual placement API ought to be complete as far as nrp goes. | |
| 18:39:21 | mriedem | and with granular requests, | |
| 18:39:35 | mriedem | you should be able to create flavors that request resources which could be found on nested resource providers in the tree right? | |
| 18:39:40 | mriedem | during GET /allocation_candidates? | |
| 18:40:11 | mriedem | reshaper is, in a nutshell, needed to fix a cheat we made in queens for vgpus | |
| 18:40:17 | mriedem | is that fair? | |
| 18:41:31 | efried | mriedem: All of that is true, but we're definitely not yet set up to where we can properly track allocations for nested providers in nova. | |
| 18:42:17 | efried | I.e. if you try to create a nrp and make a flavor that exploits it, I can guarantee you that the best that will happen is the allocations will be wrong. More likely the compute service will shit all over itself. | |
| 18:42:43 | efried | But everything from the flavor through to the GET /a_c response will be peachy. | |
| 18:43:25 | mriedem | the compute doesn't create those allocations though, scheduler does | |
| 18:43:33 | mriedem | based on the allocation request from GET /alloc_cands | |
| 18:43:53 | mriedem | if the allocations are wrong, it's because GET /allocation_candidates told us the wrong thing, yeah? | |
| 18:43:57 | dansmith | mriedem: sorry, just tending to other things, I'll look in a few | |
| 18:44:01 | mriedem | or the scheduler didn't allocate against the correct providers | |
| 18:44:14 | mriedem | i'd think the latter is the issue.. | |
| 18:44:30 | dansmith | melwitt: I wouldn't consider NRP done until we can actually use it in nova | |
| 18:44:32 | mriedem | but it shouldn't be....the providers are in the allocation request PUT body | |
| 18:44:45 | dansmith | melwitt: and that's on the other side of reshaper being done, plus the actual migration path | |
| 18:45:09 | mriedem | i'm saying i think it can be used by now, minus reshaper, | |
| 18:45:11 | efried | dansmith: The latter maybe but not the former. | |
| 18:45:13 | mriedem | otherwise i don't know what our goal is | |
| 18:45:25 | efried | mriedem: I'm saying try it, you will find nontrivial bugs with it. | |
| 18:45:41 | mriedem | that would involve some work.... | |
| 18:45:44 | dansmith | efried: I'm not sure what that means | |
| 18:45:50 | melwitt | okay, sorry I find this all pretty confusing | |
| 18:46:18 | efried | dansmith: We don't need reshaper for nrp to work. Only for situations where resources that were already being exposed on the comput node RP need to be moved. | |
| 18:46:43 | dansmith | efried: if people can't move from their cloud now to one that uses it, it doesn't work at all, IMHO | |
| 18:46:52 | dansmith | no migration path means it's a toy | |
| 18:47:08 | dansmith | and, imHO, | |
| 18:47:09 | efried | Oh, that kind of migration, I thought you meant properly migrating a VM | |
| 18:47:14 | efried | ...that uses nrp | |
| 18:47:22 | dansmith | it's not considered done unless everyone can be using it like they should, | |
| 18:47:28 | efried | "everyone"? | |
| 18:47:30 | dansmith | and not "we disabled it because we can't migrate our existing cloud" | |
| 18:47:45 | dansmith | like "users that created their cloud fresh in rocky" vs. "everyone else" | |
| 18:47:55 | efried | Right, that's not what I'm talking about. | |
| 18:48:11 | efried | Support for nrp isn't going to be a nova-wide thing, it's going to be a per-driver thing like any feature. | |
| 18:48:22 | mriedem | i think efried is saying that's only an issue for libvirt and xenserver which have vgpu inventory and allocations on the root provider yeah? but not something like powervm. | |
| 18:48:27 | efried | more specifically in fact, the features will look more like "VGPU" | |
| 18:48:32 | efried | mriedem: Yes, that. | |
| 18:48:39 | dansmith | mriedem: no, it's for everyone running libvirt with any two-socket box | |
| 18:48:44 | dansmith | which is 99% of the deployments | |
| 18:49:01 | mriedem | right, i was going to say, having said that, powervm in tree doesn't have any NRP type stuff anyway | |
| 18:49:03 | dansmith | everyone with a two-socket box from the last decade has numa | |
| 18:49:21 | efried | mriedem: Right, not yet. But very soon. | |
| 18:49:28 | efried | mriedem: And we're not blocked on reshaper, is my point. | |
| 18:49:29 | mriedem | so theoreticals aside... | |
| 18:49:33 | mriedem | efried: right i know | |
| 18:49:42 | mriedem | libvirt and xenserver are blocked on reshaper | |
| 18:49:43 | efried | It's not clear to me that dansmith knows. | |
| 18:49:48 | efried | Yes | |
| 18:50:19 | efried | However, it's possible that powervm is blocked on "client side nrp stuff we haven't exercised yet". | |
| 18:50:20 | mriedem | i think we just, generally, speak in libvirt terms, given the adoption | |
| 18:50:26 | mriedem | and how libvirt is the first to have most any new feature | |
| 18:50:51 | dansmith | yes, I understand that boutique virt drivers are not blocked in the strictest sense | |
| 18:50:56 | dansmith | from a nova project perspective, | |
| 18:51:08 | dansmith | libvirt being blocked means it's blocked, IMHO | |
| 18:51:45 | mriedem | now, cyborg or whatever could maybe totally use whatever is available today, idk | |
| 18:51:47 | efried | We should consider nrp to be the framework, and things like NUMA & VGPU support to be the features we're talking about having "nova" support. | |
| 18:52:29 | efried | So from that point of view, NUMA & VGPU are blocked "in nova" (i.e. libvirt). But the nrp framework is (probably, mostly) ready, pending working out the kinks on the client side in the scheduler. | |
| 18:52:37 | mriedem | melwitt: let me guess, you're writing up the nova release highlights thing in the releases repo? | |
| 18:53:08 | mriedem | efried: that's a good summary i think | |
| 18:53:20 | dansmith | efried: IMHO, nova's notion of NRP being done would be that existing resources we're currently lying about are converted to the new thing | |
| 18:53:27 | mriedem | melwitt: if/when you do, you should definitely mention the is_bfv disk_gb tracking stuff finally being fixed | |
| 18:53:35 | dansmith | efried: otherwise we've just created a data structure and protocol to speak about it, | |
| 18:53:40 | dansmith | but no user will perceive anything as being different | |
| 18:53:46 | efried | mriedem: Example of client-side allocation stuff that's broke: put_allocations in the report client only works for the cn rp and ignores the rest. | |
| 18:53:50 | dansmith | therefore.. we've basically accomplished nothing visible | |
| 18:54:18 | mriedem | right so lots of *nova* isn't nrp-aware | |
| 18:54:27 | mriedem | like lots of nova isn't shared storage provider aware | |
| 18:54:31 | mriedem | you can model that in placement externally, | |
| 18:54:33 | mriedem | but nova won't honor it | |
| 18:54:44 | efried | right, swhat I'm sayin. | |
| 18:55:11 | efried | So nrp in placement is done, but nrp (i.e. the framework that the actual features need) in nova is not. | |
| 18:55:20 | dansmith | yeah, so call some specific blueprint done if you want, | |
| 18:55:39 | dansmith | but when I get asked "can we do any of the things that NRP is supposed to enable for us?" I still have to answer no | |
| 18:56:02 | melwitt | mriedem: just trying to get an idea of what's currently going on there ... and taking notes | |
| 18:56:12 | efried | dansmith: Yes, I will agree with that, stipulating s/we/nova/ (as opposed to some other placement consumer). | |
| 18:56:32 | dansmith | efried: yep, been trying to tag my comments with nova when I say stuff like that | |
| 18:56:44 | dansmith | that's my intent at least | |
| 18:57:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix accumulated nits from port binding for live migration series https://review.openstack.org/583994 | |
| 18:57:16 | mriedem | efried: ^ | |
| 18:57:42 | efried | ack | |
| 18:57:54 | mriedem | dansmith: i got our lazy load thing right here too https://review.openstack.org/#/c/583994/2/nova/compute/manager.py | |
| 18:59:00 | dansmith | mriedem: ack | |
| 18:59:15 | mriedem | i intentionally said that jersey-style | |
| 19:01:45 | mriedem | unrelated, but it seems that stephen's bottom change 564440 is perpetually stuck in the check queue or something weird | |
| 19:01:51 | mriedem | it's in both queues at the same time at least twice today | |
| 19:03:42 | mriedem | and it's already failed in the gate again, | |
| 19:03:47 | mriedem | and queued in check | |
| 19:05:33 | dansmith | cripes | |
| 19:05:48 | dansmith | and some guys keep naking the later patches too | |
| 19:05:49 | dansmith | GAWD | |
| 19:06:26 | mriedem | i nak while nak'ed | |
| 19:06:35 | dansmith | naked nak? | |
| 19:06:42 | mriedem | too far | |