| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-20 | |||
| 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: Create a controller for qga when SEV is used https://review.opendev.org/693072 | |
| 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: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: Prevent deletion of a compute node belonging to another host https://review.opendev.org/694802 | |
| 19:54:27 | openstackgerrit | Mark Goddard proposed openstack/nova master: Invalidate provider tree when compute node disappears https://review.opendev.org/695188 | |
| 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 | - 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.) | |
| 20:41:29 | efried | - Treat $COMPUTE_NODE as the default and a specific name/uuid as override | |
| 20:41:29 | efried | - Index by identifier (name *or* uuid) and fail hard on conflicts there | |
| 20:41:29 | efried | Which is as follows: | |
| 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 | https://review.opendev.org/#/c/34032/ | |
| 21:22:41 | mriedem | this | |
| 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 | |
| 21:27:39 | mriedem | i'm not the guy to ask about that... | |
| 21:27:42 | eandersson | It could be some reference that keeps it alive | |
| 21:28:32 | eandersson | I poked mordred so maybe he'll get back to me tomorrow | |
| 21:28:40 | efried | I am *sure* I remember mordred telling me sdk already does local singleton-ing | |
| 21:28:48 | efried | but that doesn't mean it isn't buggy. | |
| 21:29:58 | mriedem | dansmith: this is random, but i've noticed that during a resize_claim we make at least 3 lazy-load roundtrip calls to the db to load fields that in most cases probably aren't even populated http://paste.openstack.org/show/786457/ | |
| 21:30:13 | dansmith | sweet | |
| 21:30:15 | mriedem | was wondering what you thought about adding something to Instance.refresh() to specify additional fields to load up | |
| 21:30:27 | mriedem | refresh today just pulls the instance with it's existing additional joined fields, | |
| 21:30:29 | dansmith | lazy load pci_Devices twice? | |
| 21:30:35 | dansmith | resources is the new vpmems stuff right? | |
| 21:30:43 | mriedem | pci_requests, pci_devices and resources | |
| 21:30:52 | dansmith | ah right | |
| 21:31:13 | dansmith | but sure, fresh with a extra_attrs optional param makes sense | |
| 21:31:21 | mriedem | so was thinking something like Instance.refresh(..., extra_attrs=None) yeah | |
| 21:31:27 | mriedem | it's a version bump since refresh is remotable | |