Earlier  
Posted Nick Remark
#openstack-nova - 2018-05-30
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
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

Earlier   Later