Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-08
17:11:17 fried_rice but I'm not sure why.
17:11:37 artom dansmith, so you'd rather I just straight up revert mriedem's patch? Functionally it's the same
17:11:39 cfriesen guess I'm switching to "which" then. :)
17:12:07 mriedem artom: before doing that i'd like to have a plan,
17:12:13 fried_rice cfriesen: Note that type -P doesn't check whether the thing is executable (at least on my bionic)
17:12:20 mriedem because if we know the event is coming, i don't see why we don't wait for it
17:12:29 fried_rice -rw-r--r-- 1 efried efried 4169 Mar 8 08:53 /tmp/f
17:12:29 fried_rice efried:~/openstack/nova$ ll /tmp/f
17:12:29 fried_rice f is /tmp/f
17:12:29 fried_rice efried:~/openstack/nova$ PATH=$PATH:/tmp type f
17:12:30 dansmith artom: I'm not saying a full revert vs. tactical is important
17:12:33 mriedem clearly my change worked albeit is racy
17:12:47 artom mriedem, ah, I see what you mean
17:12:49 dansmith mriedem: because it's hard to do that based on the arrangement of the code
17:12:56 mriedem artom: because i'm pretty sure i made that change b/c of gate failures
17:13:06 mriedem i.e. resize revert + ssh in tempest race fails
17:13:11 mriedem b/c we aren't waiting for plugging
17:13:19 mriedem so you revert this w/o fixing that and we've got new gate failures again
17:13:21 dansmith that's why this whole thing exists, yes
17:13:25 mriedem well, same old gate failures
17:13:33 cfriesen fried_rice: oh, good catch.
17:13:35 mriedem dansmith: we can do the same thing we do for live migration
17:13:49 dansmith can we not wait for the plug event before leaving the compute manager ?
17:13:58 fried_rice cfriesen: `which` is much better, because it also doesn't fire if the file is executable, but not by you.
17:14:03 dansmith like way before we get to the driver.finish_revert_migration() ?
17:14:26 artom dansmith, ah, right. I thought that wasn't possible because we needed the virt driver to plug the vifs
17:14:40 dansmith artom: you've been saying the virt driver isn't causing the vif plug event
17:14:41 artom But if they're already plugged, we can wait in the compute manager, and tell virt not to wait for it
17:14:43 dansmith so which is it?
17:14:49 dansmith right.
17:15:23 artom dansmith, I'm not 100% on how the Neutron agent works, but my understanding is that Neutron will only wire the thing if the virt driver had plugged it
17:15:38 dansmith artom: that contradicts what you said earlier,
17:15:39 artom So we need both: poke Neutron, and plug (or have it be already plugged)
17:15:57 dansmith which is that the vif is already on the source, so the network_api call is what is causing neutron to send the event, which we might miss if we're not fast enough
17:16:20 artom dansmith, because it was never unplugged to begin with
17:16:22 mriedem dansmith: "like way before we get to the driver.finish_revert_migration() ?" yes that's what i' msaying
17:16:56 mriedem artom: right here you are contradicting what you just said, https://review.openstack.org/#/c/639396/3/nova/compute/manager.py@4184
17:17:01 dansmith mriedem: gotcha, I'm with you now.. I thought yesterday you were saying that a straight revert was the best first step.. with this, we race in control plane code, without this, we race on the instance
17:17:02 mriedem So the times are:18:50:51.138 Update port binding 18:50:54.239 Event received 18:50:54.300 Event ignored on both computes 18:50:54.483 Driver finish_revert_migration start
17:17:06 dansmith and you could argue that the latter is better
17:17:36 dansmith I'm a little frustrated by this whole deal, so how about we table this until artom comes back from lunch and we get on a hangout?
17:17:53 mriedem sure, so we could (1) revert my change saying oopsy we still race and then (2) stack on top of that a change to wait for the event prior to changing the port binding which triggers the event
17:18:09 dansmith I don't care about the mechanics
17:18:23 mriedem yeah hangout for sure, since i'm leaving for lunch soon too
17:18:38 artom Cool. Lunch then hangout. At 13... 30?
17:18:44 artom Err, eastern time, so in an hour and 10?
17:18:45 mriedem a hangout will also give me an opportunity to show off my excessively manly beard
17:19:14 mriedem artom: like 3pm ET for me
17:19:22 mriedem which is noon for dan
17:19:22 dansmith mriedem: I assume you mean your sparse patchy white boy beard?
17:19:31 mriedem dansmith: of course
17:19:42 dansmith um, +1:10 from now is not noon for me
17:20:01 dansmith I can't be on a hangout right at noon, but before or shortly after is fine.. but noon is 2:50 from now
17:20:02 mriedem 2pm CT is noon PT yeah?
17:20:16 mriedem yes i'm saying 3PM ET or thereabouts
17:20:16 artom Speak in deltas :)
17:20:23 artom 1:10 from now?
17:20:28 mriedem no
17:20:29 dansmith omg
17:20:42 mriedem how about we just ping later
17:20:44 dansmith (the sound of a gunshot in oregon echoes through)
17:20:44 mriedem break
17:26:28 openstackgerrit Chris Friesen proposed openstack/nova master: Add emulated TPM support to Nova https://review.openstack.org/631363
17:39:39 fried_rice mriedem: I just added https://review.openstack.org/#/c/640879/ to https://etherpad.openstack.org/p/nova-stein-rc-potential -- is that a right thing?
17:40:05 mriedem that's not a regression right? it's latent since pike or queens?
17:40:21 fried_rice not a regression in stein, yes latent since several releases, will need to be backported there.
17:41:06 fried_rice so, not sure how that works; do we get it in now before rc and then backport it, or wait until stein is forked, drop it in master, wait for the dust to settle, then backport it to stable branches (including stein)?
17:41:28 mriedem technically if it's not a regression in stein it doesn't need to be stein-rc-potential (tag)
17:41:30 mriedem so the latter
17:41:36 mriedem if it's latent, we can fix it whenever and backport
17:42:16 mriedem ^ doesn't bar people from reviewing latent bug fixes before stein rc1 if they wnat
17:42:17 mriedem *want
17:42:38 mriedem just dont want to push anything in that is high risk if we don't need to
17:42:42 mriedem and i'm not saying this is high risk
17:42:45 mriedem i haven't looked it over
17:43:09 mriedem what i am saying is i'm going to lunch now
17:43:52 fried_rice thanks mriedem_burgers
19:03:11 artom mriedem_burgers, dansmith, back, ready when you are
19:04:35 dansmith I too am here
19:16:30 mriedem i'm back but
19:17:06 artom backbutt
19:17:23 dansmith as opposed to front butt?
19:18:21 mriedem gimme a minute
19:18:44 artom For what it's worth, revert https://review.openstack.org/#/c/595069/ + wait in compute manager is fine
19:18:54 artom Err, *I think that revert blah blah
19:19:21 mriedem https://hangouts.google.com/call/4MUfp6uNnY6ddII9gtXGAEEE
19:25:59 mriedem artom: see _get_neutron_events_for_live_migration for how live migration uses it
19:26:37 artom mriedem, ack
19:26:54 mriedem so i think we just wrap that around the migrate_instance_finish in finish_revert_resize
19:27:04 mriedem i'd probably split that code out to a new helper method for sanity..
19:37:42 artom Right, I gotta run again, I'll try to have those 2 patches up before the weekend
20:00:31 cfriesen so in devstack I'm running "nova migrate <uuid>" and I'm getting an error saying that it can't migrate to current host. Shouldn't it be disregarding the current host for migration?
20:03:45 dansmith cfriesen: do you only have one host?
20:03:52 cfriesen dansmith: nope, two
20:04:04 dansmith but I think you'll get that if the scheduler doesn't pick the other one as a candidate
20:04:08 cfriesen shed logs see it considering both right up till the weigher
20:04:23 cfriesen but for "migrate" we'd never want the current host
20:04:27 cfriesen only for resize
20:04:59 dansmith they're the same operation, so if allow-to-same is enabled, I think it'll allow it
20:06:10 openstackgerrit Michael Still proposed openstack/nova master: Make privsep.chown mocking for libvirt snapshot tests less magic. https://review.openstack.org/642134

Earlier   Later