| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-13 | |||
| 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 | |
| 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 | 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:03:49 | efried | openstack resource provider trait list $host_uuid | |
| 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"? | |
| 19:08:11 | dking_desktop | Oh, maybe "openstack baremetal node trait list" | |
| 19:09:45 | dking_desktop | efried: I tried "openstack baremetal node trait list <UUID>", but that gave no results. Is that the problem? | |
| 19:10:14 | efried | dking_desktop: You need to install the osc-placement plugin to get the 'resource provider' subcommands | |
| 19:10:28 | efried | pip install osc-placement (or equivalent for your distro) | |
| 19:10:43 | efried | COMPUTE_STATUS_DISABLED isn't a trait that ironic itself would know about. | |
| 19:12:59 | dking_desktop | Odd. I get "Operation or argument is not supported with version 1.0; requires at least version 1.6" | |
| 19:14:45 | dking_desktop | I wonder what software that refers to. The osc-placement package should be 1.8.0. | |
| 19:16:18 | dking_desktop | python-openstackclient is 4.0.0. Is there another way to check? It's good to know that isn't specifically an Ironic thing. However, my regular VMs work fine. It's only the baremetal nodes causing me trouble. | |
| 19:19:47 | dking_desktop | Oh, I add that to the command line. Okay, I can run that, but no mention of the above trait. | |
| 19:21:38 | dking_desktop | http://paste.openstack.org/show/789544/ | |
| 19:25:13 | dking_desktop | efried: I notice that the above output doesn't show nearly as much information as I see for my compute node. Would the problem be that there's just not any information there about the CPU, etc.? | |
| 19:26:41 | efried | dking_desktop: sorry, yes, you need to specify a microversion for almost every OSC command with placement, as OSC defaults to 1.0 and very little in placement worked at that microversion. You can use an environment variable if you'd rather not have to think about it with every command. | |
| 19:27:34 | efried | dking_desktop: When you say "as I see for my compute node", you mean a libvirt host? | |
| 19:27:58 | efried | is that what compute1.stack1 is? | |
| 19:30:45 | dking_desktop | Correct | |
| 19:30:53 | efried | Next thing to look at is the inventory of your ironic node vs. the flavor you're trying to deploy. | |
| 19:30:53 | efried | If you're seeing COMPUTE_STATUS_DISABLED in play, your control plane is at least at Train, which means your node is supposed to be at least at Stein, by which time we had cut ironic over to reporting single-unit custom resource classes. | |
| 19:31:28 | efried | something like | |
| 19:31:28 | efried | openstack resource provider inventory list (or maybe show) $node_uuid | |
| 19:31:28 | efried | should show you that. | |
| 19:31:38 | dking_desktop | I'm using train. | |
| 19:32:45 | efried | okay, so you might want to make life easier with | |
| 19:32:45 | efried | export OS_PLACEMENT_API_VERSION=1.36 | |
| 19:32:45 | efried | (I think I'm spelling that var name right) | |
| 19:32:45 | efried | Then you won't have to add --os-placement-api-version with every command. | |
| 19:32:50 | dking_desktop | Okay, that shows me the resource class and a few other pieces of info: http://paste.openstack.org/show/789545/ | |
| 19:34:06 | efried | Great. So the flavor you're using should be asking for resources:CUSTOM_BAREMETAL_RESOURCE_CLASS=1 | |
| 19:34:08 | efried | is it? | |