| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 18:32:56 | efried | melwitt: are you tracking a specific nrp blueprint? | |
| 18:32:58 | mriedem | dansmith: yeah | |
| 18:33:41 | dansmith | mriedem: are there comments on the nits one? | |
| 18:34:01 | mriedem | dansmith: yeah a few things that came from later patches in the series before he wrote the nit cleanup patch, | |
| 18:34:06 | mriedem | a couple of which are yours from the api change with the docs | |
| 18:34:20 | mriedem | i can update both if you are busy | |
| 18:34:27 | melwitt | efried: no, was just getting confused about where NRP is as a feature, in general. I think my understanding has been, it's not complete yet, and we're focusing on reshaper first to make sure the path to migration is clear and complete, then finishing NRP after that | |
| 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, | |