| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-30 | |||
| 18:09:34 | dansmith | mdbooth: if so you should be able to find it in gate logs during a resize, right? | |
| 18:10:26 | mdbooth | dansmith: Depends how long it goes unconfirmed | |
| 18:10:44 | mdbooth | But specifically the issue after resize | |
| 18:10:58 | mdbooth | Sorry, *restart* of the service | |
| 18:11:41 | mdbooth | It looks like ResourceTracker still initially populates the compute_nodes dict in update_available_resource | |
| 18:11:50 | mdbooth | Which calls driver.get_available_resource() first | |
| 18:11:56 | mdbooth | which I think would still fail | |
| 18:12:12 | mdbooth | ... so it would never be populated | |
| 18:12:36 | mdbooth | I should.. you know... actually test it :) | |
| 18:12:47 | dansmith | if you have to restart the service while something is in resize then we wouldn't hit it in the gate, | |
| 18:12:53 | dansmith | but you could write a functional test for it | |
| 18:13:10 | mdbooth | That's part 2 of the failure. Part 1 we could potentially see in the gate | |
| 18:13:15 | mdbooth | That's the DiskNotFound error | |
| 18:13:27 | dansmith | yeah | |
| 18:13:32 | mdbooth | If an instance stayed unconfirmed for more than a minute, we should see that | |
| 18:13:52 | dansmith | or we got lucky | |
| 18:14:53 | dansmith | mdbooth: mriedem <3's helping people with logstash | |
| 18:20:59 | dansmith | mdbooth: http://logs.openstack.org/96/569296/1/check/legacy-tempest-dsvm-neutron-scenario-linuxbridge/518dd97/logs/screen-n-cpu.txt#_May_30_17_38_39_176396 | |
| 18:21:12 | mriedem1 | mdbooth: dansmith: logstash taint gonna help ye | |
| 18:21:34 | dansmith | mriedem1: no? | |
| 18:21:36 | mriedem1 | because we don't have tests in tempest that wait for periodics to run in the services | |
| 18:21:50 | mriedem1 | the tempest tests would be non-deterministic and likely timeout | |
| 18:21:52 | dansmith | mriedem1: right, luck | |
| 18:21:58 | mdbooth | Yeah | |
| 18:22:01 | dansmith | I found a bunch of cases where it happens | |
| 18:22:16 | mdbooth | What did you type in the query box, btw? | |
| 18:22:16 | dansmith | here's another: http://logs.openstack.org/82/566182/5/check/neutron-tempest-ovsfw/30a3077/logs/screen-n-cpu.txt#_May_30_15_33_14_686624 | |
| 18:22:27 | mriedem1 | i've seen things where we get DiskNotFound races while the RT update periodic runs while we're concurrently deleting a server | |
| 18:22:45 | dansmith | mdbooth: message:"DiskNotFound" | |
| 18:23:01 | mriedem1 | dansmith: yup same call stack i was thinking of | |
| 18:23:29 | dansmith | mriedem1: sounds like if you restart the service in that scenario, you get really screwed | |
| 18:23:57 | dansmith | anyway, mdbooth is going to fix it up :) | |
| 18:24:01 | mriedem1 | what we need is HA nova-compute | |
| 18:24:59 | dansmith | mriedem: mo' computes, mo' pro'lems | |
| 18:25:16 | mriedem | this is the recent thing i was thinking of https://github.com/openstack/nova/commit/5f16e714f58336344752305f94451e7c7c55742c | |
| 18:26:14 | dansmith | ah, but we shouldn't stop going to the next instance and finishing update_available_resource() | |
| 18:26:28 | mriedem | we don't after that patch | |
| 18:26:38 | mriedem | depending on the state of the instance | |
| 18:26:48 | dansmith | right, but this will happen on resize, before confirm, | |
| 18:26:51 | dansmith | which means you will re-raise | |
| 18:26:56 | dansmith | since we don't undefine the domain until confirm | |
| 18:27:48 | mriedem | sure, i was just handling the race with delete bug i was seeing in the gate all the time | |
| 18:27:55 | dansmith | yup | |
| 18:27:59 | mriedem | i figured there would be additional scenarios that need to be dealt with | |
| 18:28:05 | mriedem | once mdbooth smelt what was dealt | |
| 18:30:25 | mdbooth | I don't think that patch will fix this, because it only ignores DiskNotFound if task state is set | |
| 18:30:39 | mdbooth | Which it looks like it's not between resize and confirm | |
| 18:30:41 | dansmith | mdbooth: rightI just said that :) | |
| 18:30:53 | mdbooth | dansmith: Well I wasn't looking! I was reading code. | |
| 18:30:55 | dansmith | mdbooth: that patch was for the deleting task state basically | |
| 18:30:59 | dansmith | mdbooth: keep up! | |
| 18:50:59 | melwitt | dansmith, mriedem: are we cells meeting today? looks like the CERN peeps aren't around today | |
| 18:51:17 | dansmith | oh, I have something on my calendar that covers it up so I wasn't paying attention | |
| 18:51:23 | dansmith | so yeah, cancel if we can | |
| 18:51:26 | dansmith | we just talked last week anyway | |
| 18:51:48 | melwitt | +1 | |
| 18:53:28 | mriedem | don't need to have a meeting, but tssurya has 2 bug fixes that i'm +2 on which you should probably look at | |
| 18:53:38 | melwitt | k | |
| 18:53:41 | dansmith | links | |
| 18:53:52 | mriedem | https://review.openstack.org/#/c/568271/ and https://review.openstack.org/#/c/567878/ | |
| 18:54:32 | dansmith | I'll get the second | |
| 18:54:38 | dansmith | since online migration | |
| 18:54:56 | melwitt | k | |
| 19:05:41 | mriedem | dansmith: we have backported online data migrations to fix bugs before https://review.openstack.org/#/c/408725/ | |
| 19:06:41 | dansmith | okay, probably want to do a special reno with it though right? so people (if paying attention) will know to re-run them | |
| 19:08:26 | mriedem | yeah i think so, | |
| 19:08:35 | mriedem | https://review.openstack.org/#/c/529389/ was similar but not as explicit, | |
| 19:09:01 | mriedem | the idea just being, if we can get the fix into the stable branches before people roll up to them, then great, else we tried | |
| 19:09:17 | dansmith | sure, that's a fair point | |
| 19:09:44 | dansmith | anyway, wasn't saying we couldn't or shouldn't, just that we should highlight it | |
| 19:09:45 | mriedem | should we put a simple 'fixes' reno on that patch now before backports? | |
| 19:09:57 | mriedem | then we don't need to make it weird on stable | |
| 19:10:26 | dansmith | I think a dedicated reno for the backports will make it more clear, right? "If you are applying this update after already being on the current release, you'll need to re-run online migrations" or something | |
| 19:11:21 | mriedem | sure that works for me as well | |
| 19:11:24 | dansmith | if people see that it's fixed in the stable they're running, but it's still broken for them and they don't realize they would need to re-run online migrations at a peri-release boundary they might be confused | |
| 19:12:20 | mriedem | i'll push the backport to queens once i get done with reviewing sahid's trusted vf series again | |
| 19:19:57 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: configure trust mode for vfs https://review.openstack.org/458514 | |
| 19:19:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: add vf_trusted field for network metadata https://review.openstack.org/566343 | |
| 19:19:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: metadata: add vf_trusted field to device metadata https://review.openstack.org/566344 | |
| 19:20:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: network: update pci request spec to handle trusted tags https://review.openstack.org/458820 | |
| 19:44:29 | efried | jaypipes: Done. mriedem: I'm +2 on https://review.openstack.org/#/c/553597/ now. | |
| 19:46:40 | mriedem | artom: you might want to take a quick run through this https://review.openstack.org/#/c/566344/ | |
| 19:46:47 | mriedem | efried: ok | |
| 19:47:38 | mriedem | "Snarklepuss is actually my middle name, not my surname." blows my mind | |
| 19:47:52 | mriedem | that's professional snark at a PhD level | |
| 19:48:25 | artom | mriedem, indeed, thanks for motivating me | |
| 19:48:38 | artom | That series has been sitting on my review list since forever | |
| 19:49:15 | mriedem | artom: besides that one patch i'm +2 on the rest | |
| 19:49:30 | mriedem | artom: if you're so inclined, you could even address my comments in that one and we could get the entire thing +2ed today | |
| 19:49:50 | artom | mriedem, not a bad idea, sahid's done for the day anyways | |
| 19:50:04 | artom | I don't think he'll mind | |
| 19:50:28 | artom | Will we lose all your +2s if I push/rebaes tho? | |
| 19:50:29 | mriedem | i've been addressing my own nits to keep it going | |
| 19:50:31 | mriedem | so yeah he won't mind | |
| 19:50:34 | mriedem | no | |
| 19:50:41 | artom | "rebaes" | |
| 19:50:52 | mriedem | if you rebase like you spell, we might have problems | |
| 19:50:53 | artom | When you come back to your bae | |
| 19:51:03 | tssurya | mriedem, dansmith: thanks for the reviews, I just got back from a (2 weeks long) vacation and also don't have anything for the meeting. Will catch up on the summit stuff from tomorrow. | |
| 19:51:16 | dansmith | tssurya: cool | |