| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-20 | |||
| 17:00:40 | mnaser | so its possible i hit node4+node5 which is a bad time | |
| 17:00:50 | dansmith | efried: I think it'd be good to get some jroll input on this | |
| 17:00:57 | efried | agree | |
| 17:01:01 | sean-k-mooney | if node 0,2,3 could fit it it would select 0 and 2 | |
| 17:01:06 | sean-k-mooney | and never check 3 | |
| 17:01:09 | dansmith | efried: but I think people will be pretty surprised if it's gone | |
| 17:01:15 | mnaser | sean-k-mooney: so far im seeing some numbers increasing by 25% -- and ok i see | |
| 17:01:42 | efried | dansmith: but then we go back to needing the association in the instance meta, because there's nothing else | |
| 17:02:20 | sean-k-mooney | mnaser: that is why i said we liekly could optimise this using the numa distance but its more complex then what we do today | |
| 17:02:29 | dansmith | efried: image meta you mean? I'm not saying we should, I'm just poking holes in it which.. if people lose data they get mad | |
| 17:02:30 | sean-k-mooney | mnaser: and it has implciations for modeling in plamcent | |
| 17:02:33 | dansmith | efried: I'm on a call right now though | |
| 17:02:36 | efried | sorry, yeah, image meta. | |
| 17:02:37 | mnaser | sean-k-mooney: yes that sounds massively complex to get implemented -- but would be so awesome | |
| 17:03:12 | sean-k-mooney | mnaser: what feature that relates to numa isint :) | |
| 17:03:18 | mnaser | hah, good one | |
| 17:03:30 | mnaser | sean-k-mooney: i mean in my case, the fact memory doesnt float across 8/16 numa nodes, at least 2 is better, the only "bad" potential idea is if a VM get pinned to two NUMA nodes that are pretty far apart | |
| 17:03:58 | sean-k-mooney | right as in on different sockets. | |
| 17:04:07 | mnaser | yep | |
| 17:04:17 | sean-k-mooney | but even then its still better then floating as it will be deterministic | |
| 17:04:53 | sean-k-mooney | well in that once the instnace i booted its performance should not change | |
| 17:17:50 | openstackgerrit | Merged openstack/nova stable/train: Imported Translations from Zanata https://review.opendev.org/694911 | |
| 17:32:45 | openstackgerrit | Boris Bobrov proposed openstack/nova master: Create a controller for qga when SEV is used https://review.opendev.org/693072 | |
| 17:34:27 | KeithMnemonic | any change to please get some reviews on the "marker" patches mriedem was working on ? https://review.opendev.org/#/c/690721/4 Thanks! | |
| 17:36:59 | dustinc | efried, gibi, dansmith: RE Provider Config: Just got caught up on this morning's convo. Am I right in seeing that you guys want to A) drop NAME as identification method, and B) Allow both $UUID and $COMPUTE_NODE to identify same RP but $UUID takes precedence? If so I am 100% on board. | |
| 18:06:45 | dansmith | dustinc: I dunno about a conflict between a fixed uuid and $compute_node, but I would recommend handling that the same way I suggested for the name/uuid conflict, which is to log error and ignore both | |
| 18:33:04 | openstackgerrit | Boris Bobrov proposed openstack/nova master: Also enable iommu for virtio controllers and video in libvirt https://review.opendev.org/684825 | |
| 18:33:04 | openstackgerrit | Boris Bobrov proposed openstack/nova master: Create a controller for qga when SEV is used https://review.opendev.org/693072 | |
| 18:49:19 | sean-k-mooney | by the way i just looked at the implemented spec folder for train. looks like we have not moved them https://github.com/openstack/nova-specs/tree/master/specs/train/implemented | |
| 19:09:08 | mriedem | sean-k-mooney: you can run this and post the results https://github.com/openstack/nova-specs/blob/master/tox.ini#L39 | |
| 19:14:48 | sean-k-mooney | sure just leaving to grab dinner but ill give it a try when i get back | |
| 19:15:49 | sean-k-mooney | ok so that checks with launchpad to determin if they were finsihed and then updates them | |
| 19:16:03 | sean-k-mooney | cool | |
| 19:54:26 | openstackgerrit | Mark Goddard proposed openstack/nova master: Clear rebalanced compute nodes from resource tracker https://review.opendev.org/695187 | |
| 19:54:27 | openstackgerrit | Mark Goddard proposed openstack/nova master: Invalidate provider tree when compute node disappears https://review.opendev.org/695188 | |
| 19:54:27 | openstackgerrit | Mark Goddard proposed openstack/nova master: Prevent deletion of a compute node belonging to another host https://review.opendev.org/694802 | |
| 19:54:28 | openstackgerrit | Mark Goddard proposed openstack/nova master: Fix inactive session error in compute node creation https://review.opendev.org/695189 | |
| 20:38:41 | efried | dustinc: The way I suggested yesterday still works IMO, and it requires less churn in both design and already-written code. | |
| 20:40:13 | efried | With dansmith's addendum | |
| 20:41:29 | efried | Which is as follows: | |
| 20:41:29 | efried | - Index by identifier (name *or* uuid) and fail hard on conflicts there | |
| 20:41:29 | efried | - Treat $COMPUTE_NODE as the default and a specific name/uuid as override | |
| 20:41:29 | efried | - If a provider appears such that you do find a conflicting name+uuid, log an error and ignore that provider completely. (This should only be possible for *nested* providers.) | |
| 21:00:15 | efried | dansmith: shelve without offload only works for non-volume-backed, right? | |
| 21:01:53 | efried | and followup question, should we do the swift thing for shelve without offload, or only with offload? I guess the question is a) does unshelve always happen on same host in that case; b) do we care about "shelving" the minimal amount of storage required by the vdev? | |
| 21:02:14 | artom | sean-k-mooney, as promised, if you still have energy today, https://review.opendev.org/#/c/691062/ is ready again | |
| 21:02:23 | efried | probably yes to b), just for the sake of form, so shelving the vdev would be the right thing to do. | |
| 21:04:12 | efried | guess it really just makes sense to make it part of snapshot and have a crisp line | |
| 21:13:47 | mriedem | efried: shelve works for volume-backed and non-volume-backed | |
| 21:14:23 | efried | mriedem: In the compute API I see that volume-backed calls the shelve-offload code path. | |
| 21:14:29 | mriedem | if you shelve but don't offload (which offloading is automatic by default config) then you unshelve within the offload window you do end up on the same host (conductor just starts the server) | |
| 21:15:29 | efried | https://opendev.org/openstack/nova/src/branch/master/nova/compute/api.py#L3867-L3873 ? | |
| 21:15:36 | mriedem | yeah so in the case of volume-backed shelve there is no snapshot image | |
| 21:16:02 | efried | right, but the distinction for 'offload' (at least the one that I care about) is that it calls destroy() | |
| 21:16:06 | efried | whereas non-offload doesn't. | |
| 21:16:16 | efried | uh, unless I got confused. | |
| 21:16:34 | efried | yeah | |
| 21:16:47 | mriedem | yeah shelve without offload powers off the guest and creates a snapshot | |
| 21:17:33 | efried | ack | |
| 21:18:17 | mriedem | i'm drawing a blank on why we shelve offload immediately for volume-backed servers | |
| 21:19:19 | mriedem | just ask one of these guys from 2013 https://review.opendev.org/#/c/34032/ | |
| 21:19:46 | efried | was gonna say, seems like it's been that way from the get-go. dansmith co-authored, so... | |
| 21:19:51 | efried | he'll surely know. | |
| 21:20:31 | mriedem | i guess this comment https://review.opendev.org/#/c/34032/21/nova/compute/manager.py@3099 | |
| 21:20:44 | dansmith | mriedem: because there's no reason not to offload immediately | |
| 21:20:48 | efried | probably because waaay back then, the distinction with offload was only whether snapshot was necessary, which it isn't for volume (right?) | |
| 21:20:50 | dansmith | mriedem: there's no point in maintaining affinity | |
| 21:21:18 | dansmith | efried: not just no snapshot required, but there's no benefit to unshelve to the same host before offload | |
| 21:21:32 | dansmith | once offloaded, it's might as well go anywhere, but before offload, it's much quicker if you stay put | |
| 21:21:45 | dansmith | but with volume-backed, that distinction does not exist | |
| 21:21:49 | efried | got it. | |
| 21:22:02 | dansmith | efried: also, did you say I co-authored something? | |
| 21:22:08 | mriedem | i didn't realize the offload periodic came later https://review.opendev.org/#/c/35361/ | |
| 21:22:25 | dansmith | oh that shelve patch | |
| 21:22:32 | dansmith | I dunno what I co-authored about it | |
| 21:22:36 | dansmith | not much | |
| 21:22:37 | mriedem | not that one | |
| 21:22:41 | mriedem | this | |
| 21:22:41 | mriedem | https://review.opendev.org/#/c/34032/ | |
| 21:23:09 | dansmith | right | |
| 21:23:12 | efried | co-authored *and* +2ed, tsk | |
| 21:23:22 | efried | those were rowdy times | |
| 21:23:24 | eandersson | Anyone got any experience with the openstacksdk interacting with nova. Trying to figure out how to fix a memory leak in Senlin. | |
| 21:23:32 | dansmith | efried: never uploaded a patch set, | |
| 21:23:46 | efried | eandersson: you mean nova talking through sdk, or using sdk to talk to nova? | |
| 21:23:47 | dansmith | efried: so that was probably honorary because I helped figure something out | |
| 21:23:54 | eandersson | using the sdk to talk to nova | |
| 21:24:51 | efried | eandersson: mmph. Not so hot there. Given you already met crickets in -sdks, mriedem and I might between us be able to figure things out... | |
| 21:25:28 | eandersson | Senlin seems to be creating a new client for everytime it makes a call to nova. Which isn't ideal. | |
| 21:25:51 | efried | and you think that's because of the way it's talking to sdk? | |
| 21:25:53 | eandersson | I wanted to make it a singleton, but not sure how to do that when the user/project might differ. | |
| 21:26:07 | eandersson | https://review.opendev.org/#/c/695139/4/senlin/profiles/base.py | |
| 21:26:18 | eandersson | If you look at like 489 there | |
| 21:26:22 | eandersson | *389 | |
| 21:26:52 | eandersson | So I know for sure the leak is caused by the openstacksdk | |
| 21:26:56 | mriedem | so create a singleton map per user/project hash? | |
| 21:27:12 | eandersson | Yea - was going to go that route, but seems crazy to me hehe | |
| 21:27:22 | mriedem | obviously it's just masking a leak | |
| 21:27:25 | eandersson | Isn't there a way I can just create one openstacksdk object and re-use it | |
| 21:27:28 | mriedem | but idk why the sdk would be leaking | |