| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-14 | |||
| 16:59:59 | brinzhang | efried, gmann, melwitt: Thank you very much. | |
| 17:00:22 | dansmith | Sundar: I'll have to see it, but I think that makes sense for reschedule | |
| 17:02:57 | brinzhang | dansmith: Agree, add the delete arqs operation in _cleanup_when_reschedule_fails(), I think make sense. | |
| 17:04:50 | efried | bauzas: now | |
| 17:04:58 | bauzas | ack | |
| 17:05:08 | efried | bauzas: do you want me to make the edit? | |
| 17:05:19 | openstackgerrit | Ilya Etingof proposed openstack/nova master: Add JSON schema and test for network_data.json https://review.opendev.org/703133 | |
| 17:05:24 | bauzas | efried: nah, can do | |
| 17:05:26 | efried | k | |
| 17:05:31 | bauzas | Atom is still open | |
| 17:06:07 | artom | 'sup? Oh. | |
| 17:06:56 | efried | do you seriously have a notifier for 'atom'? | |
| 17:06:56 | bauzas | LOL | |
| 17:06:59 | artom | Nah, I just happen to be procrastinating in here | |
| 17:07:03 | efried | :) | |
| 17:07:11 | efried | shoot, if you want to read some specs... | |
| 17:07:36 | efried | on second thought, never mind. Don't want to risk a -1 at this stage... | |
| 17:07:42 | artom | Haha | |
| 17:08:05 | artom | So, it's short-term procrastination, waiting for a command to run | |
| 17:08:42 | efried | oh | |
| 17:08:45 | efried | see, I call that "working" | |
| 17:09:00 | efried | back in the day, when waiting for compiles, play some guitar. | |
| 17:09:02 | efried | "working". | |
| 17:09:34 | artom | Also, I thought spec deadline was yesterday? | |
| 17:11:16 | efried | artom: ahem, "this week". | |
| 17:13:10 | bauzas | running tox and then uploading | |
| 17:18:22 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs https://review.opendev.org/552924 | |
| 17:19:15 | openstackgerrit | Merged openstack/nova master: Skip to run all integration jobs for policy-only changes. https://review.opendev.org/707268 | |
| 17:20:35 | melwitt | brinzhang: no, I was saying I think it should be allow delete_on_termination for both new swap volume and old volume | |
| 17:22:15 | efried | bauzas: Looks good, thanks. I'll wrangle the +A from here (hopefully). | |
| 17:22:47 | efried | stephenfin: I think that +A is pretty much yours https://review.opendev.org/#/c/552924/ | |
| 17:45:08 | openstackgerrit | Merged openstack/nova stable/queens: Block deleting compute services with in-progress migrations https://review.opendev.org/699718 | |
| 17:45:44 | efried | gibi: if you happen to check back in, you could also be that +A https://review.opendev.org/#/c/552924/ | |
| 17:49:51 | artom | efried, FWIW I think stephenfin's off this afternoon | |
| 17:50:00 | artom | So it's up to... not sure who, actually | |
| 17:52:43 | efried | artom: ugh, okay, thanks for the info. Guess I need to decide whether his/gibi's previous +2s encompass enough of the current iteration for me to proxy them. | |
| 17:54:13 | efried | ...yeah, no, I can't do that. | |
| 17:54:32 | artom | dansmith lulz | |
| 17:55:36 | dansmith | what? | |
| 17:56:36 | artom | Sorry, was trolling. We're out of cores in the correct timezone to +A the NUMA RPs spec | |
| 17:57:21 | efried | I don't think attempting to drag dansmith back in is the right answer. | |
| 17:57:31 | artom | I know - hence the "trolling" | |
| 17:58:04 | artom | Oh great, func tests are broken on queens | |
| 17:58:12 | artom | I know upstream doesn't care, but Red Hat does :P | |
| 17:58:23 | efried | gmann_afk: is that ^ something you were working on? | |
| 17:58:54 | efried | artom: gmann had some fixes in stable, but perhaps they didn't make it all the way back to q. Are you aware or want me to dig? | |
| 18:00:08 | efried | artom: nm, apparently q was included https://review.opendev.org/#/q/topic:fix-stable-gate+status:merged | |
| 18:00:21 | artom | efried, I found some things, but yeah, they're for tempest, and exist in queens | |
| 18:00:22 | efried | so if still broken, I guess it's something else? (or you need a rebase?) | |
| 18:01:40 | artom | I'm basically getting https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1807262 | |
| 18:01:40 | openstack | Launchpad bug 1807262 in nova (Ubuntu) "stein unit tests fail with sqlalchemy.exc.NoSuchTableError: migration_tmp" [High,Fix released] | |
| 18:02:56 | efried | artom: meaning you need to backport a req bump to sqla 0.12.0? | |
| 18:04:05 | artom | efried, apparently | |
| 18:04:30 | efried | artom: I'll join you in -requirements, but I thought that was a thing we don't do. | |
| 18:05:03 | artom | efried, yeah, it seems wide-hitting to me | |
| 18:05:18 | efried | how is it just cropping up, then? | |
| 18:05:44 | efried | artom: I guess you might want to confirm that that version of sqla fixes your issue before pursuing. | |
| 18:06:27 | artom | efried, backporting a thing to downstream queens, func test failed, since we suck and don't have an easy way to run downstream func tests locally, I figured a backport to queens might hit the same issue | |
| 18:06:33 | artom | Instead, I hit a different one | |
| 18:06:48 | artom | *This* one :) | |
| 18:06:59 | efried | note that nova/U bumped past 0.12.0 to 0.13.0 for unrelated reasons https://review.opendev.org/#/c/690704/ so you would need a stable-only patch starting in train. | |
| 18:07:12 | artom | And actually bumping to 0.12.0 does nothing | |
| 18:07:19 | efried | okay then. | |
| 18:07:22 | efried | artom: what are you backporting downstream? | |
| 18:07:48 | artom | efried, https://review.opendev.org/#/q/Iafba419fe86446ffe636721f523fb619f8f787b3 | |
| 18:08:30 | efried | artom: well, confirming that 0.12.0 shouldn't fix the issue, the fact that that's already in r/s/t and those guys aren't using 0.12.0... | |
| 18:09:09 | artom | efried, yeah. And actually, q is em, so I could try and push it | |
| 18:09:17 | artom | See what the gate says, maybe it's local to me... | |
| 18:09:38 | efried | swhat I would do. | |
| 18:09:52 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: Add functional regression recreate test for bug 1839560 https://review.opendev.org/707886 | |
| 18:09:52 | openstack | bug 1839560 in OpenStack Compute (nova) stein "ironic: moving node to maintenance makes it unusable afterwards" [High,Fix committed] https://launchpad.net/bugs/1839560 - Assigned to Matt Riedemann (mriedem) | |
| 18:09:52 | openstackgerrit | Artom Lifshitz proposed openstack/nova stable/queens: Restore soft-deleted compute node with same uuid https://review.opendev.org/707887 | |
| 18:10:04 | artom | And while that runs, I need lunch | |
| 20:14:02 | gmann | efried: artom it was working till morning with latest fix of stachviz. | |
| 20:15:17 | gmann | this stable/queens got in today- https://review.opendev.org/#/c/699718/ | |
| 20:16:26 | spatel | sean-k-mooney: question if you around | |
| 20:17:23 | spatel | when we do cpu pinning in that case does openstack make sure it properly map with sibling? | |
| 20:17:41 | artom | gmann, thanks, I'll try with and without that change | |
| 20:18:47 | gmann | artom: but i would not be surprise if there is new one :) by seeing current frequency of 1-2 issue per day on stable branches. | |
| 20:19:00 | artom | gmann, ack | |
| 20:21:50 | artom | gmann, yeah, no, still happening without that last change | |
| 20:22:35 | artom | gmann, however, it seems it's only happening on my machine... | |
| 20:24:01 | gmann | artom: until you have updated stable constraint locally or something. may be recreate tox can help ? | |
| 20:24:20 | artom | gmann, I've been doing *nothing but* recreates :) | |
| 20:24:29 | gmann | :) | |
| 20:43:45 | spatel | Does anyone know what would be the advantage of hw:cpu_thread_policy=require | |
| 20:44:08 | spatel | currently i have default which is "prefer" | |
| 20:44:25 | spatel | I am seeing performance issue so trying to understand what would be the advantage | |
| 20:48:11 | efried | spatel: let me know if this doesn't help: https://docs.openstack.org/nova/latest/admin/cpu-topologies.html#customizing-instance-cpu-thread-pinning-policies | |
| 20:48:43 | spatel | efried: i am on same page but i am trying to understand language | |
| 20:48:50 | efried | ah | |
| 20:49:14 | efried | this is not my area of expertise. Normally I would call on stephenfin or sean-k-mooney, but I think they're out at the moment. artom, how's your understanding here? | |
| 20:50:25 | spatel | currently i am seeing on vm siblings are not correctly align with my physical cores... | |
| 20:50:48 | spatel | look like cpu_thread_policy=require may fix that but wanted to understand first before i just go and play | |
| 20:51:42 | artom | spatel, it's getting into the nitty gritty of low level CPU arch, which is not my strong point | |
| 20:52:13 | artom | But IIUC putting workloads on thread siblings (policy=require) means the content for the hardware that's shared between the two threads | |
| 20:52:35 | artom | I *think* there would be 2 decoding units, but a single execution unit | |
| 20:53:06 | artom | So if your workload is CPU heavy, I would advice against putting it on thread sibligns, and use policy=isolate (at the cost of unusable CPU threads) | |
| 20:53:29 | spatel | we are running Erlang application which is CPU and memory bound | |
| 20:53:30 | artom | *means there's contention | |