Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-12
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
16:35:43 sean-k-mooney enable_numa_live_migration is used in the api i think and reject any live migration if the instnace has a numa toplogy when set to false which we made the defaul.
16:36:40 sean-k-mooney the reasoning being while it was a behavior change teh people that understand how to deploy numa toployg are the people that modify thing in the config anyway and we whould not let most people break things by migaint with out understandint its broken with numa

Earlier   Later