| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-08 | |||
| 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 | dansmith | mriedem: I assume you mean your sparse patchy white boy beard? | |
| 17:19:22 | mriedem | which is noon for dan | |
| 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 | artom | Speak in deltas :) | |
| 17:20:16 | mriedem | yes i'm saying 3PM ET or thereabouts | |
| 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 | mriedem | break | |
| 17:20:44 | dansmith | (the sound of a gunshot in oregon echoes through) | |
| 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 | |
| 20:06:12 | cfriesen | okay, but that makes no sense logically to the user. a "migrate" operation should mean moving it elsewhere. | |
| 20:06:40 | dansmith | cfriesen: yeah, I'm not arguing that it makes sense, I'm just stating what I think is the case | |
| 20:06:57 | dansmith | also, migrate is admin-only by default I think, so it might not get much visibility because of that | |
| 20:07:10 | cfriesen | I suspect you're right. but it means that with "resize on same host" enabled you currently have to explicitly specify a destination. | |
| 20:07:29 | dansmith | no, | |
| 20:07:37 | cfriesen | I'm pretty sure this is a regression, just not sure from when | |
| 20:07:41 | dansmith | it only means that if your current host is the most obvious target right? | |
| 20:08:03 | cfriesen | dansmith: okay, fair enough. it means you can't assume it won't land on the current host | |
| 20:08:30 | dansmith | I dunno how common it is to have allow-to-current enabled in production either | |
| 20:08:41 | dansmith | it was supposed to only be for gate testing | |
| 20:09:00 | cfriesen | It's useful in small clouds. | |
| 20:09:21 | dansmith | again, stating the original intent | |
| 20:09:24 | cfriesen | what was the rationale for defaulting it to "off"? | |
| 20:09:40 | dansmith | because it was only for testing | |
| 20:10:48 | cdent | tautology! | |