| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-26 | |||
| 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 | |
| 19:10:13 | melwitt | mriedem: so the shared storage counting local usage for volume-backed instances saga is finally over? | |
| 19:11:28 | mriedem | not shared storage | |
| 19:11:31 | mriedem | volume-backed root_gb | |
| 19:12:05 | mriedem | https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/nova+branch:master+topic:bug/1469179 | |
| 19:12:06 | melwitt | oh, I think I got that confused with shared storage reporting. that's still not done | |
| 19:12:26 | melwitt | ok | |
| 19:12:38 | mriedem | we will no longer claim root_gb for volume-backed instances against DISK_GB inventory in placement for new instances | |
| 19:12:41 | mriedem | and heal on moves | |
| 19:13:33 | dansmith | shared ephemeral reporting is also fixed in rocky I think | |
| 19:13:42 | mriedem | via placement? | |
| 19:13:48 | dansmith | we no longer report DISK_GB in inventory if MISC_SHARES_VIA_AGGREGATE is set | |
| 19:14:16 | mriedem | for the libvirt driver* | |
| 19:14:46 | mriedem | i wouldn't talk much about that in rocky though, because we have several places in the code that don't handle that | |
| 19:14:50 | dansmith | not sure, I would have expected that to be applied to each as they converted to update_provider_tree(), unless the others are still using get_inventory() | |
| 19:15:08 | openstackgerrit | Dan Smith proposed openstack/nova master: Assorted cleanups from numa-aware-vswitches series https://review.openstack.org/582651 | |
| 19:15:09 | openstackgerrit | Dan Smith proposed openstack/nova master: Add additional functional tests for NUMA networks https://review.openstack.org/585385 | |