| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-30 | |||
| 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:16 | mdbooth | What did you type in the query box, btw? | |
| 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 | |
| 19:51:41 | mriedem | tssurya: rest assured we talked you up big time to belmiro and tim in vancouver | |
| 19:51:56 | tssurya | mriedem: haha thanks a ton!! | |
| 19:52:42 | mriedem | artom: just: git review -d 458820 && git rebase -i HEAD~2 | |
| 19:52:52 | mriedem | fix the one, then git rebase --continue && git review -R -y | |
| 19:53:29 | artom | Ah, yeah, rebasing on the one below it instead of master isn't a bad idea | |
| 19:53:35 | artom | Tiny bit patronizing tho ;) | |
| 19:54:08 | mriedem | right don't rebase on master | |
| 19:54:15 | mriedem | that makes the diffs between patches hard to follow | |
| 19:54:38 | mriedem | i only rebase on master if i have a merge conflict | |
| 19:54:59 | artom | At some point, someone somewhere will make a diff of diffs tool | |
| 19:55:08 | artom | I remember Diana talking about it before she left Red hat | |
| 19:55:17 | dansmith | git review can do that for ou | |
| 19:55:21 | mriedem | tonyb probably already has one | |
| 19:55:39 | artom | dansmith, yeah? Will need to look into that | |
| 19:55:44 | dansmith | git review -m XXX,4,5 | |
| 19:56:03 | mriedem | i'm currently explaining the difference, over text message, between bratwurst, kielbasa and summer sausage | |
| 19:56:10 | mriedem | and can't tell if it's some cruel joke | |
| 19:56:29 | dansmith | git review can't do that | |
| 19:56:48 | dansmith | git review will do anything for love, but it won't ... doo... thaaat. | |
| 19:56:51 | mriedem | git review --sausage-index | |
| 19:56:54 | dansmith | hah | |
| 19:57:24 | dansmith | I think you just did | |
| 19:57:38 | artom | So meta | |
| 20:01:03 | artom | mriedem, so is 'vf_trusted' always going to show in device metadata from now on? And set to True/False? | |
| 20:01:22 | artom | Or it'll only appear if the VF is trusted? | |