| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-12 | |||
| 15:41:07 | openstackgerrit | Jing Zhang proposed openstack/nova master: Remove the current host from cold migration target host list https://review.opendev.org/675025 | |
| 15:51:30 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Avoid timeout from service update notification tests https://review.opendev.org/675935 | |
| 15:56:40 | mriedem | cdent: up your vmware alley https://review.opendev.org/#/c/675025/2 | |
| 15:56:52 | cdent | sounds a bit rude, that | |
| 15:57:00 | mriedem | ha | |
| 15:58:06 | mriedem | dansmith: efried: melwitt: what do you think about the [workarounds]/allow_cold_migrate_to_same_host idea in https://review.opendev.org/#/c/675025/ as a backportable thing until we can be smarter about scheduling for cold migrate based on compute capabilities / traits filtering? | |
| 16:00:50 | dansmith | mriedem: meaning different behavior for cold migrate vs. resize? | |
| 16:01:11 | mriedem | yeah | |
| 16:01:35 | mriedem | the existing option conflates them which is bad for everything except vmware | |
| 16:01:41 | dansmith | the intent of cold migration is always to land it on a different host, so I guess I'm not sure why the patch is wrong (in intent, I haven't looked at the reasoning) | |
| 16:02:04 | mriedem | that's true for everything except vcenter | |
| 16:02:29 | dansmith | okay so the workaround config knob would only need tweaking for vmware? | |
| 16:02:32 | cdent | yet another raeson for vogan | |
| 16:02:42 | mriedem | dansmith: yeah | |
| 16:02:50 | melwitt | I'm not opposed to the patch but isn't this a super latent thing or? surprised this hasn't come up before | |
| 16:02:55 | mriedem | and is a backportable thing until we can be smarter about filtering based on traits | |
| 16:03:00 | mriedem | melwitt: it is, | |
| 16:03:06 | mriedem | there are a bunch of related bugs | |
| 16:03:07 | dansmith | mriedem: and that workaround would be read/honored in api or conductor when assembling the request to scheduler/ | |
| 16:03:12 | mriedem | we just never do anything about fixing it :) | |
| 16:03:18 | melwitt | heh, wow | |
| 16:03:19 | mriedem | dansmith: api | |
| 16:03:29 | mriedem | dansmith: same place that allow_resize_to_same_host is read | |
| 16:03:47 | dansmith | yeah | |
| 16:04:00 | dansmith | for some reason I feel like workarounds are usually per-host and thus read by the compute | |
| 16:04:02 | dansmith | and further, | |
| 16:04:15 | dansmith | if you have one vmware compute and a bunch of libvirt computes, you likely don't want that to be a global policy | |
| 16:04:36 | mriedem | sure, but we already do, | |
| 16:04:47 | dansmith | for resize you mean | |
| 16:04:51 | mriedem | and that's why i think long-term we replace the workaround option with traits-based compute capability filtering, | |
| 16:05:03 | mriedem | yes, but we treat reaize == cold migrate in the api from this regard | |
| 16:05:23 | dansmith | sure, but the stated goal of allowing resize to same host makes more sense as a global I think | |
| 16:05:27 | dansmith | but anyway, what I'm saying is: | |
| 16:06:07 | dansmith | maybe the knob should be read by compute and factor in to what traits it exposes and then let the control side throw some required or forbidden trait in there | |
| 16:06:19 | mriedem | you can't backport that | |
| 16:06:29 | mriedem | but yes, that's what i'm saying we do with https://review.opendev.org/#/c/666604/ | |
| 16:06:29 | dansmith | sure | |
| 16:06:48 | mriedem | compute exposes a trait for if it can do a thing, api reads that and configures the request spec for scheduler filtering appropriately, | |
| 16:06:54 | dansmith | but if we add it as honored by control, then backport that, then we kinda need deprecation or a dance to move to the per-compute way | |
| 16:06:56 | mriedem | which replaces the workaround thing i'm suggesting for backports | |
| 16:07:04 | mriedem | correct | |
| 16:07:15 | mriedem | workaround option -> backports -> eventual deprecation with the new thing https://review.opendev.org/#/c/666604/ | |
| 16:07:21 | dansmith | right, so point is, since this is latent since the beginning of time, I don't care so much about the backport | |
| 16:07:38 | dansmith | but if it's super important to you then, I guess whatever | |
| 16:08:03 | mriedem | it's not super important to me, it's just i've dealt with it more than once and it continues to come up as a bug for *us* | |
| 16:08:27 | mriedem | my fear is the longer we don't do something, the more hack patches like this show up | |
| 16:08:55 | dansmith | ack | |
| 16:09:34 | sean-k-mooney | mriedem: speaking about https://review.opendev.org/#/c/666604/? | |
| 16:10:02 | mriedem | related yes | |
| 16:10:11 | mriedem | prompted by https://review.opendev.org/#/c/675025/ | |
| 16:10:14 | sean-k-mooney | we spoke about it a bit on irc and understand the motivaition more now | |
| 16:10:25 | mriedem | the royal we? | |
| 16:10:38 | sean-k-mooney | as in i pinging you about it last week | |
| 16:10:43 | sean-k-mooney | or the week before | |
| 16:10:51 | sean-k-mooney | and you explained what it was for | |
| 16:11:32 | sean-k-mooney | it is not a trait i would expect to see in a flavor or image | |
| 16:11:46 | sean-k-mooney | but i can see how it could be useful in this specific case | |
| 16:12:02 | melwitt | I'm ok with the wokraround conceptually, I'm not sure why we didn't just do that years ago. I'm assuming it's a really simple change to consider resize different than cold migrate for "allow same host" | |
| 16:12:57 | mriedem | sean-k-mooney: nor are several of our compute-capability based traits | |
| 16:13:04 | mriedem | melwitt: yeah i think it would be a small change | |
| 16:13:12 | mriedem | if allow_resize_to_same_host: | |
| 16:13:32 | mriedem | if cold_migrate and allow_cold_migrate_to_same_host: | |
| 16:13:33 | sean-k-mooney | a workaround config option has the benifit that it could be backported were as the trait could not | |
| 16:13:39 | mriedem | dude | |
| 16:13:53 | melwitt | lol | |
| 16:14:25 | sean-k-mooney | i know dansmith just said he does not care | |
| 16:14:32 | sean-k-mooney | and ye just finished that conversation | |
| 16:14:48 | sean-k-mooney | but it is a minor pluse to the workaround still for me | |
| 16:15:04 | sean-k-mooney | *workaround conf | |
| 16:15:23 | melwitt | the reason I ask is because I wouldn't support a workaround like this for a super latent thing if it's a big complicated change. but if it's a tiny one liner and would solve a lot of pain for people, then it seems like a worthwhile thing to do | |
| 16:16:33 | melwitt | my concern would be more like, do we really expect to deprecate it from [workarounds] or not | |
| 16:16:42 | dansmith | I don't think it's a lot of people, and I just want to avoid the deprecation dance, effectively introducing something as deprecated | |
| 16:16:44 | dansmith | but yes, it's small and the deprecation is the major impact, so whatever | |
| 16:17:05 | dansmith | melwitt: I assume we'd land it, and deprecate it in the next patch, then just backport the first one | |
| 16:17:21 | melwitt | oh, right, I see | |
| 16:17:30 | mriedem | yes that would be what i'd do | |
| 16:18:04 | sean-k-mooney | dansmith: that depend on the long term fix no? e.g. if we make it work transparently in the fureure then the deprecation/removal should not break people | |
| 16:18:14 | dansmith | sean-k-mooney: we can't | |
| 16:18:28 | dansmith | sean-k-mooney: we're talking about moving what honors the thing from global/scheduler to local/compute | |
| 16:18:34 | dansmith | didn't we already discuss that part? | |
| 16:19:35 | sean-k-mooney | oh i missed that part of the discussion. ill go back to fixing my typos :) | |
| 16:20:07 | sean-k-mooney | i had assumed the workaround option would be set globally | |
| 16:21:25 | melwitt | if the trait thing is simple and we're sure we're going to land it this cycle, then deprecate immediately "works". immediate deprecation is definitely a weird thing to do having left it latent for so long, but if it's such a minor tiny change, I'm not opposed about it | |
| 16:22:36 | melwitt | *backport + immediate deprecation | |
| 16:22:49 | sean-k-mooney | it would not be the first workaound option that has been in that state | |
| 16:23:13 | sean-k-mooney | e.g the numa migration one was intended to be intoduced backported and deprecated all in one cycle | |
| 16:24:04 | openstackgerrit | Merged openstack/nova stable/queens: Disable limit if affinity(anti)/same(different)host is requested https://review.opendev.org/659247 | |
| 16:24:08 | sean-k-mooney | we even change default behavior with that backport | |
| 16:29:01 | openstackgerrit | Matt Riedemann proposed openstack/nova master: rt: only map compute node if we created it https://review.opendev.org/675704 | |
| 16:29:03 | openstack | bug 1839560 in OpenStack Compute (nova) "ironic: moving node to maintenance makes it unusable afterwards" [High,In progress] https://launchpad.net/bugs/1839560 - Assigned to Matt Riedemann (mriedem) | |
| 16:29:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional regression recreate test for bug 1839560 https://review.opendev.org/675705 | |
| 16:30:35 | sean-k-mooney | if we treated the new can_cold_migrate_to_same_node workaround option the same way as enable_numa_live_migration is there a reason we cant just set this gloably the scheduler? | |
| 16:30:51 | sean-k-mooney | i know that would not be desirebal for mix hyperviors | |
| 16:31:03 | sean-k-mooney | but its simplifies thing greatly | |
| 16:31:09 | dansmith | sean-k-mooney: could you read the backscroll please? | |
| 16:31:15 | dansmith | we've already discussed that too | |
| 16:31:52 | dansmith | or even the comments on the patch | |
| 16:31:53 | sean-k-mooney | ok im just confused why we would treat this differently then enable_numa_live_migration which is effectivly the same | |
| 16:32:01 | sean-k-mooney | ill read both | |
| 16:32:34 | dansmith | it probably should be the same, I haven't really seen anything about that knob myself | |