| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-12 | |||
| 11:34:06 | stephenfin | gibi, bauzas: Could you take a look at this requirements patch today? https://review.opendev.org/c/openstack/nova/+/775142 | |
| 11:34:26 | bauzas | I can try | |
| 11:34:36 | stephenfin | We're trying to uncap a dependency (PrettyTable) and need to do that across multiple projects | |
| 11:36:48 | bauzas | gibi: stephenfin, others: I just spotted the fact that most of our prefilters don't raise exceptions but one | |
| 11:37:13 | bauzas | do we have kind of a consensus about a prefilter error behaviour ? | |
| 11:37:38 | bauzas | if so, I should catch the exceptions I raise in the subsequent modules | |
| 11:37:59 | stephenfin | hmm, I've no idea. Depends on what happens with those exceptions. Do we capture them or would it result in a HTTP 5xx? | |
| 11:38:02 | bauzas | or raising them nested into a RequestFilter exc | |
| 11:38:17 | bauzas | the caller is a prefiler, so that's async | |
| 11:38:22 | bauzas | prefilter* | |
| 11:38:48 | bauzas | the scheduling phase should set an ERROR state, that's it | |
| 11:38:58 | bauzas | exactly like a NoValidHosts | |
| 11:39:09 | bauzas | hence the questionj | |
| 11:39:33 | bauzas | I'm OK with nesting any exception within a RequestFilter exception so we make consistent behaviour | |
| 11:39:42 | gibi | bauzas: that sounds like a good behavior. Set the instance to ERROR and let the create instance action store the exception | |
| 11:40:04 | stephenfin | Ah yes, I see what you mean | |
| 11:40:06 | bauzas | ok then stephenfin's point about better exception handling is legit | |
| 11:40:19 | stephenfin | the other filters just log and return False | |
| 11:41:08 | bauzas | right but there is the require_tenant_aggregate() prefilter which does this too | |
| 11:41:15 | bauzas | hence my question | |
| 11:41:26 | bauzas | looks like we hadn't thought about this | |
| 11:41:35 | bauzas | not saying the other filters don't raise exceptions | |
| 11:41:57 | bauzas | their own calls could fail too, that's just they don't handle them straight | |
| 11:42:07 | gibi | explicit failure is better than simply skipping the prefilter behavior and move forward with the scheduliung | |
| 11:42:36 | stephenfin | Yeah, we don't seem to do anything with the return values | |
| 11:42:39 | stephenfin | outside of tests | |
| 11:42:59 | stephenfin | process_reqspec simply calls the filter - it doesn't do anything with the return value | |
| 11:43:14 | stephenfin | so raising does seem like a sensible thing to do, if it's something we can't recover from | |
| 11:43:28 | stephenfin | and we should probably do the same for the other filters | |
| 11:44:46 | bauzas | gibi: a filter generally can fail without blocking | |
| 11:45:04 | bauzas | we don't hard stop on a scheduler filter failure iirc | |
| 11:45:35 | bauzas | honestly, I don't know what to say | |
| 11:45:38 | gibi | hm, so if the NumaTopologyFilter borks on a request then we simply ignore the NUMA part of the request? | |
| 11:45:49 | bauzas | checking, unsure | |
| 11:47:04 | bauzas | gibi: there is a precedent : https://bugs.launchpad.net/nova/+bug/1473308 | |
| 11:47:06 | openstack | Launchpad bug 1473308 in OpenStack Compute (nova) "NUMATopologyFilter raise exception and not continue filter next node when there is no wanted pagesize in current filtered host" [Medium,Fix released] - Assigned to Chung Chih, Hung (lyanchih) | |
| 11:47:21 | bauzas | here, we decided to catch the exception and continue filtering | |
| 11:47:53 | bauzas | so the utils and network methods can fail and raise, but the prefiler has to handle those | |
| 11:48:02 | gibi | we assumed that if we fail to filter a host then that host is bad, but other host might be good | |
| 11:48:11 | bauzas | right | |
| 11:48:17 | gibi | but a prefilter is not per host | |
| 11:48:26 | bauzas | good call | |
| 11:48:34 | gibi | it is applied globally on the placement a_c query | |
| 11:48:35 | bauzas | I'm tore | |
| 11:48:39 | bauzas | torn* | |
| 11:55:39 | bauzas | stephenfin: the PrettyTable reqs bump is a bit frightening | |
| 11:55:50 | bauzas | we're crossing 2 major releases | |
| 11:56:02 | stephenfin | There's no bump | |
| 11:56:10 | stephenfin | It's still constrained by upper-constraints | |
| 11:56:30 | stephenfin | https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L143 | |
| 11:56:55 | stephenfin | that will eventually be raised, but it'll just be like anything else being increased | |
| 11:57:34 | bauzas | does the community has a plan for bumping ? | |
| 11:57:46 | bauzas | hopefully they won't just raise the bar at the top | |
| 11:57:56 | bauzas | but rather incrementing it slowly | |
| 11:58:09 | stephenfin | not yet, though I have checked and the 2.0.0 API is identical to the 0.7.2 API | |
| 11:58:24 | stephenfin | The major version bump just indicates that Python 2 support was dropped | |
| 11:59:15 | stephenfin | I had to make one change in cliff to get things working with 2.0.0, and that was only because the previous version had a bug that we were inadvertently benefiting from :) | |
| 11:59:33 | bauzas | ack | |
| 11:59:38 | stephenfin | context https://review.opendev.org/c/openstack/cliff/+/774915 | |
| 12:31:32 | kashyap | stephenfin: Hey, a random question: what OS is your base Xeon server running? | |
| 12:31:49 | stephenfin | It's powered off atm, but typically Ubuntu 20.04 | |
| 12:31:53 | stephenfin | cos that's what the gate runs | |
| 12:32:20 | stephenfin | Fedora on my laptop | |
| 12:32:40 | kashyap | I see; that's still fine. Perhaps next week, I might ask to test something for me. Let me know when you powered it on :) | |
| 12:32:53 | stephenfin | ack | |
| 12:33:00 | kashyap | Is it reason to assume that you enable nested KVM by default on your kernel? | |
| 12:33:21 | stephenfin | yup | |
| 12:33:46 | openstack | bugzilla.redhat.com bug 1928103 in libvirt "libvirt insists on including extra CPU features that were not asked for: "vme,x2apic,hypervisor"" [Unspecified,New] - Assigned to libvirt-maint | |
| 12:33:46 | kashyap | Cool; thank you. (It's in relation to a libvirt upstream bug I just filed: https://bugzilla.redhat.com/show_bug.cgi?id=1928103) | |
| 12:34:07 | kashyap | Disregard it for now :) | |
| 12:47:01 | openstackgerrit | Merged openstack/nova master: Uncap PrettyTable https://review.opendev.org/c/openstack/nova/+/775142 | |
| 13:49:10 | openstackgerrit | Elod Illes proposed openstack/placement master: Add periodic-stable-jobs template https://review.opendev.org/c/openstack/placement/+/775384 | |
| 13:56:31 | bauzas | ∕me disappears for a haircut (thanks 6pm curfew= | |
| 14:34:43 | dansmith | stephenfin: I've seen you recheck a few things due to no space on disk...where are you seeing that? | |
| 14:34:54 | dansmith | last week we had a problem with devstack running out of disk installing apt packages, | |
| 14:34:58 | dansmith | but this seems different? | |
| 14:35:18 | dansmith | I'm trying to collect cinder fails to take to the cinder team, so if you're seeing it in cinder logs, I'd like to know | |
| 14:37:47 | dansmith | ah, subnode c-vol I see | |
| 14:38:07 | dansmith | er, no that's different | |
| 14:39:40 | stephenfin | dansmith: https://zuul.opendev.org/t/openstack/build/8997228d3c5740688d78d8f9c94e3421/log/job-output.txt#2724 | |
| 14:40:05 | dansmith | oh interesting | |
| 14:40:33 | dansmith | oh I was looking at the nova-next fail on check anyway | |
| 14:41:24 | dansmith | that's the same 15g worker that was causing the problem | |
| 14:44:50 | sean-k-mooney | dansmith: 15G zuul executor? | |
| 14:45:02 | dansmith | yeah | |
| 14:45:08 | sean-k-mooney | ah ok | |
| 14:45:58 | sean-k-mooney | ya that could be an issue. i thought all the git repos used to be about 8G but with the gerrit reviews moving to the git repos i guess they have got bigger | |
| 14:47:11 | gmann | dansmith: can you check this,. added release notes too as you asked https://review.opendev.org/c/openstack/placement/+/775214 | |
| 14:47:12 | dansmith | sean-k-mooney: was working on this with fungi last week and he added a df to the output, and we only start devstack with like 3G available | |
| 14:47:42 | dansmith | gmann: will look | |
| 14:47:47 | gmann | thanks | |
| 14:48:05 | sean-k-mooney | the gate vms are ment to have 80G of disk space but not all has to be mounted under root | |
| 14:48:23 | sean-k-mooney | we try to fix it but is this just with one provider | |
| 14:50:10 | sean-k-mooney | those requiremnet are documented here https://docs.opendev.org/opendev/system-config/latest/contribute-cloud.html | |
| 15:28:47 | fungi | yeah, i wasn't able to narrow down what's causing it. seems like sometimes we're getting nodes in that one provider which have a way smaller rootfs than normal. most of the nodes booted in that provider, even from the same image and flavor, have a 100gb rootfs but occasionally we get one with only 15gb, like somehow the growroot at boot didn't work for unknown reasons | |
| 16:02:45 | openstackgerrit | Merged openstack/nova master: Rename ensure_network_metadata to amend requested_networks https://review.opendev.org/c/openstack/nova/+/773955 | |
| 16:21:50 | openstackgerrit | Merged openstack/placement stable/victoria: Fix l-c job and move to latest hacking 4.0.0 https://review.opendev.org/c/openstack/placement/+/775214 | |
| 16:38:18 | dansmith | gibi: what do you think? https://review.opendev.org/c/openstack/nova/+/775293 | |
| 16:38:27 | dansmith | could go bigger but figure it's good to let it soak a bit on a couple jobs | |
| 16:42:20 | dansmith | those are some pretty complex jobs so the fact that it seems to work there, assuming it continues to, should be high confidence I think | |