| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-13 | |||
| 17:24:06 | bauzas | stephenfin: the failback query should only be for 'NUMA-aware' instances | |
| 17:24:18 | bauzas | .... aaaaand I probably messed this up | |
| 17:24:24 | bauzas | (in the last rev of the spec) | |
| 17:24:26 | stephenfin | we want to make sure a non-NUMA instance will not land on a NUMA host, but long term shouldn't we also make sure a NUMA instance won't land on a non-NUMA host? | |
| 17:24:54 | bauzas | stephenfin: yeah | |
| 17:25:16 | stephenfin | okay, then you need to find some way to indicate that yes, this *really* is a non-NUMA host | |
| 17:26:31 | stephenfin | that way your queries can be "give me all NUMA hosts and all unconfigured hosts, but *not* any non-NUMA hosts" | |
| 17:26:35 | stephenfin | and vice versa | |
| 17:26:36 | stephenfin | right? | |
| 17:26:51 | bauzas | sec, wrapping up things in my mind | |
| 17:27:05 | efried | so by your proposal, we actually need a three-way conf opt in U. | |
| 17:27:07 | bauzas | there are two timeframes in my mind | |
| 17:27:27 | bauzas | Ussuri where hosts can be unconfigured | |
| 17:27:36 | bauzas | (because default is no reshape) | |
| 17:27:38 | stephenfin | in a future release, those would simply become "give me all NUMA hosts" or "give me all non-NUMA hosts", depending on your instance type | |
| 17:27:49 | bauzas | Victoria where all hosts are configured | |
| 17:27:50 | stephenfin | efried: yeah, I was thinking a boolean that defaults to None | |
| 17:27:57 | stephenfin | I think we can do that | |
| 17:28:02 | stephenfin | none/unset | |
| 17:28:15 | efried | - "This host is NUMA" ==> reshape, only land hw:numa* flavors | |
| 17:28:15 | efried | - "This host is not NUMA" ==> no reshape, only land non-hw:numa* flavors | |
| 17:28:15 | efried | - None (default in U) ==> no reshape, looks just like a T host, land either type of flavor | |
| 17:28:27 | stephenfin | yup | |
| 17:28:32 | bauzas | I can write this | |
| 17:28:37 | efried | and then, what, make None illegal in V?? | |
| 17:28:47 | bauzas | efried: I'm cool with it | |
| 17:28:50 | efried | Thus breaking upgrades?? | |
| 17:28:54 | bauzas | nope | |
| 17:28:55 | stephenfin | V, W, X, ... at some point in the future | |
| 17:28:56 | bauzas | becaue | |
| 17:29:00 | bauzas | because, | |
| 17:29:04 | bauzas | we can test things | |
| 17:29:18 | bauzas | and see 'okay, look, this is harmless' | |
| 17:29:28 | bauzas | so, once we all agree, we remove the None value | |
| 17:29:29 | stephenfin | essentially this would become one of the things you have to configure | |
| 17:29:43 | stephenfin | like 'compute_driver' | |
| 17:29:45 | bauzas | and de facto all instances act upon NUMA checking | |
| 17:29:45 | efried | I mean, if we're going to segregate eventually, then at some point we "break upgrades". | |
| 17:30:03 | efried | btw, dansmith specifically said he didn't want two modes long term. | |
| 17:30:36 | stephenfin | yeah, but by that point they'll have had a couple of cycles of warnings saying "yo, you *really* need to set this config option" | |
| 17:30:56 | stephenfin | efried: yeah, I don't understand why that's a bad thing | |
| 17:31:18 | dansmith | I officially give up, please proceed. | |
| 17:31:26 | efried | sigh | |
| 17:31:28 | stephenfin | I get that all instances should have some kind of NUMA awareness | |
| 17:31:30 | efried | okay, back to PS16 | |
| 17:32:51 | efried | stephenfin: tbc, if we go this route, we don't need can_split ever, right? | |
| 17:33:04 | stephenfin | but it's a nice-to-have and I don't imagine everyone really cares | |
| 17:33:26 | stephenfin | efried: correct | |
| 17:33:52 | stephenfin | if we're going with the "everything is mapped to NUMA", then I think we should move the ball forward on 'can_split' instead | |
| 17:34:07 | stephenfin | because if we don't, it won't ever happen :) | |
| 17:34:30 | stephenfin | implement that, then use it for NUMA in V | |
| 17:34:42 | bauzas | folks, you lost me | |
| 17:35:17 | stephenfin | but as cdent saw from the openstack-discuss thread, no one's really asking for their NUMA-based instance to coexist alongside their "I don't care about NUMA"-based instances | |
| 17:35:44 | stephenfin | bauzas: A boolean '[compute] enable_numa' option that default to unset (None) | |
| 17:35:56 | efried | bauzas: that ^, but otherwise PS16. | |
| 17:36:29 | stephenfin | when unset, we start flashing a warning saying "you need to decide if this host is meant for NUMA-based instances or not" | |
| 17:36:35 | stephenfin | i.e. "go configure this option" | |
| 17:36:41 | bauzas | and no 'everything is NUMA and good luck finding a host that can fit your non-NUMA instance ?" | |
| 17:36:56 | stephenfin | not needed, IMO | |
| 17:37:09 | bauzas | yeah I agree | |
| 17:37:20 | stephenfin | it's so much more additional complexity for idk how much gain | |
| 17:37:28 | bauzas | ok, it's 6:37pm here and I will have to eat soon | |
| 17:37:39 | bauzas | I'm rushing over providing another round | |
| 17:38:47 | stephenfin | Yeah, I've to go but feel free to +2 in my absence if the spec roughly maps to the above ^^^ I'm onboard with that approach | |
| 17:39:22 | efried | As PTL I decree that we can do the final approvals tomorrow morning. | |
| 17:39:37 | efried | rather than try to rush it through "tonight". | |
| 17:40:29 | stephenfin | sounds good to me (y) | |
| 17:42:00 | bauzas | efried: I appreciate your help but I'll still stick with working on a rev tonight | |
| 17:42:12 | efried | k | |
| 17:42:41 | stephenfin | huaqiang: https://review.opendev.org/#/c/668656/ acked too, btw. Thanks for sticking with that | |
| 17:42:42 | efried | saying, I won't proxy stephenfin's +2 tonight; it's fine to wait til morning for that. | |
| 17:42:55 | efried | ah, woot | |
| 17:45:06 | efried | gibi: re DISK_GB, save me reading the comment history, are you saying that the nova spec will be dependent on the placement change? | |
| 17:45:44 | efried | ...an because the placement change won't happen in U, therefore the nova bp can be deferred? | |
| 17:58:50 | openstackgerrit | Lee Yarwood proposed openstack/nova master: virt: Provide block_device_info during rescue https://review.opendev.org/700811 | |
| 17:58:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Add support for stable device rescue https://review.opendev.org/700812 | |
| 17:58:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Report COMPUTE_RESCUE_BFV and check during rescue https://review.opendev.org/701429 | |
| 17:58:52 | openstackgerrit | Lee Yarwood proposed openstack/nova master: api: Introduce microverion 2.82 allowing boot from volume rescue https://review.opendev.org/701430 | |
| 17:58:52 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Extract _get_bdm_image_metadata into nova.utils https://review.opendev.org/705212 | |
| 18:00:09 | efried | brinzhang: What's the story on https://review.opendev.org/#/c/580336/ (bp/destroy-instance-with-datavolume)? We're at spec freeze... | |
| 18:02:35 | openstackgerrit | Merged openstack/nova-specs master: Use PCPU and VCPU in one instance https://review.opendev.org/668656 | |
| 18:03:07 | gmann | efried: can you remove -2 from this now as spec is merged and good to code- https://review.opendev.org/#/c/701609/ | |
| 18:04:32 | efried | gmann: Since we're at spec freeze, we should probably wait until we've decided which unfinished blueprints should be Direction:Approved. | |
| 18:04:42 | efried | If the code were ready, that would be different, but... | |
| 18:05:22 | gmann | efried: code is in progress so i am not sure if author still confuse with -2 | |
| 18:05:47 | efried | gmann: We can help educate the author :P | |
| 18:05:48 | gmann | but ok to wait till Direction:Approved decision | |
| 18:07:34 | gmann | commented on review the same. | |
| 18:20:03 | efried | melwitt: are you now owning nova-audit? (https://review.opendev.org/#/c/693226/) | |
| 18:20:46 | melwitt | efried: I didn't want to but I think the answer is technically yes because dansmith lost interest | |
| 18:21:28 | efried | melwitt: well, I ask because we're at spec freeze, so you need to get a couple cores on board, ahem, today if it's going to happen in ussuri. | |
| 18:22:26 | bauzas | efried: melwitt: FWIW, this is related https://review.opendev.org/#/c/670112/ | |
| 18:22:43 | efried | it is? | |
| 18:22:54 | bauzas | technically, it's just a rename | |
| 18:23:08 | bauzas | but the intent of the spec is to provide a new specific command AFAICR | |
| 18:23:20 | bauzas | this change ^ would just be another subcommand | |
| 18:24:34 | melwitt | efried: yeah, I don't think that's going to happen. operators are interested but the spec didn't attract review from cores thus far and I don't think I could wrangle two that would not be considered part owners by the end of today | |
| 18:25:30 | efried | melwitt: if "tomorrow" would make the difference, I'm fine with that. Or do you just want me to defer? | |
| 18:26:28 | melwitt | bauzas: the intent of the spec is to organize all of the heal commands in one place and make them runnable as a daemon service so that they automatically heal your cloud periodically | |
| 18:27:27 | bauzas | oh missed the last part | |