| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-13 | |||
| 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 | efried | I mean, if we're going to segregate eventually, then at some point we "break upgrades". | |
| 17:29:45 | bauzas | and de facto all instances act upon NUMA checking | |
| 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: compute: Report COMPUTE_RESCUE_BFV and check during rescue https://review.opendev.org/701429 | |
| 17:58:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Add support for stable device rescue https://review.opendev.org/700812 | |
| 17:58:52 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Extract _get_bdm_image_metadata into nova.utils https://review.opendev.org/705212 | |
| 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 | |
| 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 | |
| 18:27:31 | bauzas | gtk | |
| 18:28:01 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.opendev.org/552924 | |
| 18:28:10 | bauzas | efried: ^ | |
| 18:28:12 | efried | ack | |
| 18:29:18 | bauzas | anyway, bailing out | |
| 18:29:21 | melwitt | efried: I guess yeah if you'll give it till tomorrow, I'll send some email and see if anyone's willing to review. if there's not interest after that, then punt it | |
| 18:29:34 | Sundar | dansmith: If https://review.opendev.org/#/c/673735/37/nova/conductor/manager.py@524 is not the right place to delete ARQs on a reschedule, do you have any suggestion for a better plac? I could do it in the callers. | |
| 18:29:51 | efried | melwitt: ack. I'm adding it (with other open specs) to today's meeting agenda, if you want to drum up interest there. | |
| 18:29:55 | dansmith | melwitt: efried it seems highly unlikely that anything would get implemented in U either way, so I'm not sure it's worth that | |
| 18:30:16 | dansmith | I thought we were supposed to be trying to reduce the number of things we approved that aren't likely to make it, | |
| 18:30:36 | dansmith | but it kinda seems like we're doing the same ol' kind of behavior | |
| 18:31:18 | dansmith | Sundar: do it where it needs to be done, not inside a thing called something else.. so yes, wherever that's called from that is the right place | |
| 18:32:37 | melwitt | dansmith, efried: well, I could implement it quickly/dumbly (I'm imagining just moving the commands and adding a service) but getting review would be another story. worst case it sits there ready to go for V if ppl can't review in time. so, I dunno | |
| 18:33:21 | efried | dansmith: Yes, intend to do a sweep of Definition:Approved blueprints "soon" to decide which of those we can/should defer. | |
| 18:34:06 | efried | "spec freeze" -- no more definition approvals -- is what's happening now. | |
| 18:37:54 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add Unified Limits Spec https://review.opendev.org/602201 | |
| 18:45:32 | efried | johnthetubaguy: Save me looking, did you squash the fup? | |
| 18:45:38 | efried | (abandon if so) | |
| 18:51:31 | dking_desktop | I'm attempting to troubleshoot why I get the "No valid host was found." error when attempting to create a baremetal server, and just found this when I enabled debugging for the nova-scheduler: compute_status_filter request filter added forbidden trait COMPUTE_STATUS_DISABLED | |
| 18:52:07 | dking_desktop | Could that be the reason why I'm not able to find a valid host? How would I troubleshoot this further? | |
| 19:03:49 | efried | openstack resource provider trait list $host_uuid | |
| 19:03:49 | efried | dking_desktop: We always add that trait. It's only going to have an effect if the compute host is exposing that trait. You can check with a command like | |
| 19:04:01 | efried | (I may not have the syntax exactly right -- see the docs) | |
| 19:07:00 | dking_desktop | I'm using Ironic if that helps. I don't see anything for "openstack resource". Is it "openstack service provider list"? | |