| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-08 | |||
| 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! | |
| 20:10:49 | cfriesen | I get that, but why was it only for testing? You're trying to resize, why would you force a migration too? | |
| 20:12:11 | dansmith | cfriesen: there were some reasons discussed originally when it was added, but it's been a long time.. probably mostly around how the major users of this stuff ran their clouds at the time | |
| 20:12:27 | dansmith | i.e. packing like flavors together | |
| 20:13:04 | dansmith | again, not saying it makes sense today, just saying why it was done that way | |
| 20:13:23 | cfriesen | currently I'd expect the scheduler to trigger it to move in that case | |
| 20:16:13 | cfriesen | anyways, reported it as a bug: https://bugs.launchpad.net/nova/+bug/1819216 | |
| 20:16:13 | openstack | Launchpad bug 1819216 in OpenStack Compute (nova) "in devstack, "nova migrate <uuid>" will try to migrate to the same host (and then fail)" [Undecided,New] | |
| 20:19:16 | mriedem | did someone say resize to same host problems?! https://review.openstack.org/#/c/638791/ | |
| 20:19:31 | mriedem | if you have servers in an affinity group, you can *only* resize to the same ohst | |
| 20:19:32 | mriedem | *host | |
| 20:19:58 | mriedem | cfriesen: there is also a bug for the thing you hit, semi-related anyway | |
| 20:20:38 | cfriesen | mriedem: right, I knew about the affinity group | |
| 20:20:51 | mriedem | the api says resize to same host, sure, but the compute says 'no way' | |
| 20:22:04 | mriedem | https://bugs.launchpad.net/nova/+bug/1811235 | |
| 20:22:05 | openstack | Launchpad bug 1811235 in OpenStack Compute (nova) "instance's vm-state becomes error when cold-migrate instance to same host failed" [Medium,In progress] - Assigned to Matt Riedemann (mriedem) | |
| 20:23:07 | mriedem | the api check is here https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3626 | |
| 20:23:43 | mriedem | the compute check is here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4287 | |
| 20:24:04 | mriedem | which fails for everything except vmware | |
| 20:24:23 | mriedem | since vmware is a cluster and you can migrate within the same "host" | |
| 20:25:11 | mriedem | so allow_resize_to_same_host is true if you're doing a resize, but not a cold migration *unless* you've got vcenter | |
| 20:26:10 | cfriesen | arguably the scheduler should only allow cold migration to same host for vcenter | |
| 20:26:22 | mriedem | the scheduler doesn't know if it's vcenter | |
| 20:26:23 | cfriesen | I guess it's actually the conductor | |
| 20:26:27 | mriedem | or conductor | |
| 20:26:39 | mriedem | the control plane services are not supposed to know anything about the underlying compute driver | |
| 20:26:43 | cfriesen | can't we look at host capabilities or hypervisor type or something? | |
| 20:27:02 | dansmith | cfriesen: and make assumptions? what about vmware 2 which *can* do that thing.. it's a slippery slope | |
| 20:27:07 | dansmith | separation of responsibilities | |
| 20:27:11 | cdent | vmware even has a downstream patch which adds config for "always resize to same "host" " | |
| 20:28:19 | mriedem | cdent: that's kind of where https://review.openstack.org/#/c/638791/ is going | |
| 20:28:28 | cfriesen | how do we handle it for live migration? | |
| 20:28:50 | mriedem | we always ignore the source host | |
| 20:29:01 | mriedem | same for evac | |
| 20:29:18 | cfriesen | seems weird to make live migration and cold migration behave differently | |
| 20:31:47 | mriedem | so, | |
| 20:31:53 | mriedem | now that we report compute driver capabilities as traits, | |
| 20:31:56 | mriedem | and supports_migrate_to_same_host is a driver capability, | |
| 20:32:20 | mriedem | we could technically check the compute node provider traits for the source compute node from the api and determind if it supports cold migrate to the same host and filter the request spec appropriately | |
| 20:32:46 | dansmith | don't you need the opposite of that? | |
| 20:33:10 | dansmith | you need to know if it *needs* the same host for the vmware case, not whether not it *can* yeah? | |
| 20:33:57 | mriedem | yeah maybe, you can't cold migrate across clusters | |
| 20:33:59 | mriedem | right? | |