| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 17:44:45 | dansmith | I don't see any other uses of asserting the 500.. did I miss them? | |
| 17:45:08 | mriedem | some tests assert the fault | |
| 17:45:38 | dansmith | I can't get the reason in the 500 unfortunately | |
| 17:45:55 | mriedem | self.assertIn('No valid host', six.text_type(ex)) | |
| 17:46:04 | dansmith | s'not in there | |
| 17:46:17 | dansmith | oh, the exception name is though | |
| 17:46:23 | dansmith | but not the string like normal | |
| 17:46:29 | mriedem | good enough for a test | |
| 17:46:36 | dansmith | ytup | |
| 17:47:27 | mriedem | fwiw i've tried to write new functional tests without CastAsCall as much as possible to avoid stuff like this, and force the functional tests to be written from a user perspective so we have to get faults and stuff like that | |
| 17:48:41 | mriedem | doesn't help you in these b/c of the layers of base class setup | |
| 17:49:11 | dansmith | yeah | |
| 17:49:35 | mriedem | it's like a bean dip after the sour cream at the bottom has gone bad | |
| 17:49:38 | dansmith | that rebuild test is fairly useful now, fwiw | |
| 17:49:44 | openstackgerrit | Dan Smith proposed openstack/nova master: Add additional functional tests for NUMA networks https://review.openstack.org/585385 | |
| 17:49:45 | dansmith | heh | |
| 17:50:00 | dansmith | man I should get a C-A-B on this at this point | |
| 17:52:59 | mriedem | do it | |
| 17:55:19 | openstackgerrit | Dan Smith proposed openstack/nova master: Add additional functional tests for NUMA networks https://review.openstack.org/585385 | |
| 17:55:23 | dansmith | omg I feel so much better | |
| 18:04:34 | Multiple_ | Looking for further review from sometime , please have a look https://review.openstack.org/#/c/563418/ | |
| 18:19:46 | openstackgerrit | Merged openstack/nova master: [placement] Extract base functional test case from test_direct https://review.openstack.org/585777 | |
| 18:22:07 | mriedem | efried: commented on https://review.openstack.org/#/c/583994/1/nova/network/neutronv2/api.py@410 - just let me know which you prefer | |
| 18:28:24 | melwitt | efried: can you remind me please again, is NRP done or are there remaining bits that will go after reshaper? | |
| 18:29:52 | openstackgerrit | karim proposed openstack/nova master: Updated AggregateImagePropertiesIsolation filter illustration https://review.openstack.org/586317 | |
| 18:32:18 | mriedem | dansmith: now that you co-own that, are you going to make the updates to both it and the nit cleanup patch below it? | |
| 18:32:25 | mriedem | dansmith: or shall i? | |
| 18:32:39 | efried | mriedem: Responded. | |
| 18:32:49 | dansmith | mriedem: to the functional test one? | |
| 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. | |