| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-06 | |||
| 12:14:42 | kashyap | artom: I have a half draft sitting; will send something "soon" | |
| 12:14:55 | artom | kashyap, appreciated :) | |
| 12:14:55 | kashyap | artom: Based on the description notes here: https://bugs.launchpad.net/nova/+bug/1780138 | |
| 12:14:56 | openstack | Launchpad bug 1780138 in OpenStack Compute (nova) "Don't assume the guest machine type to be of 'pc'" [Medium,Confirmed] - Assigned to Kashyap Chamarthy (kashyapc) | |
| 12:15:03 | lyarwood | mdbooth: it would be pretty transparent if we hadn't | |
| 12:15:27 | mdbooth | Presumably snapshot would be failing on ceph | |
| 12:15:38 | mdbooth | Why isn't the upstream gate broken? | |
| 12:15:50 | lyarwood | upstream gate is py2 | |
| 12:16:04 | lyarwood | right, actually ceph is still nv on py2 | |
| 12:16:20 | lyarwood | ceph py3 is in the experimental queue | |
| 12:16:48 | mdbooth | lyarwood: Ack. So this looks like a fix we approve of, but probably not a downstream blocker. | |
| 12:17:16 | mdbooth | Should be high priority upstream, though. | |
| 12:51:58 | kashyap | sean-k-mooney: So I dug the upstream logs of #virt channel, and the "max 28" thing for PCIe ports came from this: | |
| 12:52:53 | kashyap | [For aarch64, *apparently*:] | |
| 12:53:05 | kashyap | <paste> | |
| 12:53:06 | kashyap | 13:23 < hrw> ok. 28 pcie-root-port entries are maximum | |
| 12:53:06 | kashyap | 13:23 < hrw> 29 == uefi dumps to shell instead of booting | |
| 12:53:06 | kashyap | 13:25 < abologna> hrw: that might be a bug rather than an actual limit, but there's a limit of 256 on... something? possibly devices, each pcie-root-port has 8 functions so that would be 31 to get to 256 devices | |
| 12:53:10 | kashyap | 13:25 < abologna> hrw: except pcie-root-ports are of course devices themselves | |
| 12:53:13 | kashyap | 13:25 < abologna> hrw: and even after plugging in 28 pcie-root-ports some of pcie-root's slots and functions will be empty | |
| 12:53:16 | kashyap | 13:26 < hrw> will discuss that with our uefi developers ;D | |
| 12:53:19 | kashyap | </end-paste-spam> | |
| 12:53:40 | kashyap | [That snippet is from Feb 2018, BTW] | |
| 12:53:40 | sean-k-mooney | ok so we should leave it at 28 and just set teh default to 28 | |
| 12:54:41 | kashyap | sean-k-mooney: I wondering if I should step into the rabbit hole to test with an AArch64 guest -- to see what is the current limitation? | |
| 12:55:24 | kashyap | sean-k-mooney: As abologna, the author of https://libvirt.org/pci-hotplug.html, seems to imply the 28 is not even a valid limit. | |
| 12:55:37 | sean-k-mooney | kashyap: proably not as we cant assume they are using a new version of qemu or whatever impose the 28 limit on arrch64 | |
| 12:56:29 | kashyap | sean-k-mooney: The thing is, we're not sure that 28 is an _actual_ limit or not. Nobody seem to have confirmed. | |
| 12:57:06 | sean-k-mooney | if you want to grab a aarch64 guest image and test then sure | |
| 12:57:21 | sean-k-mooney | but we shoudl play it safe with the default | |
| 12:57:41 | kashyap | Yeah, let me do the test. I want to be sure. | |
| 13:07:37 | stephenfin | gibi: Any chance you could take a look at https://review.opendev.org/#/c/660774/ again today and hit me up if you need more info? | |
| 13:07:56 | gibi | stephenfin: give me an hour | |
| 13:08:01 | stephenfin | ta | |
| 13:08:03 | gibi | stephenfin: I'm on a meeting now | |
| 13:08:10 | stephenfin | All good. Thanks :) | |
| 13:22:13 | kashyap | Does anyone here (or know someone who) uses OpenStack on AArch64? | |
| 13:23:12 | sean-k-mooney | there are some folk from lenaro that hang out on the openstack-kolla irc form time to time | |
| 13:25:52 | stephenfin | kashyap: Might want to talk to tonyb | |
| 13:26:40 | kashyap | stephenfin: Yep, noted | |
| 13:27:05 | kashyap | sean-k-mooney: Yeah, I was looking for 'hrw' | |
| 13:29:11 | kashyap | sean-k-mooney: What a beast this whole PCIe saga is | |
| 13:30:47 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Remove 'Debug' middleware https://review.opendev.org/662506 | |
| 13:32:38 | sean-k-mooney | kashyap: well its in good hands. we could just do nothing and leave it to the operator to configur the config for there needs which is what nova originally opted to do | |
| 13:33:08 | sean-k-mooney | but if there is a sane default then that is also a good outcome too | |
| 13:33:16 | sean-k-mooney | brb | |
| 13:33:30 | kashyap | sean-k-mooney: Yeah, indeed. But was just exclaiming about the general subtlety involved here... | |
| 13:41:32 | lyarwood | mriedem / efried ; https://review.opendev.org/#/c/663011/ - morning, if you have time to day I'm looking for some non-RH core review on this libvirt specific bugfix. There's a change on top of this that's testing the q35 machine type in the gate. I'm looking into the extend volume failure at the moment. | |
| 13:41:53 | efried | lyarwood: looking | |
| 13:52:26 | efried | lyarwood: Are you looking to backport this? | |
| 13:53:38 | lyarwood | efried: only to stable/stein | |
| 13:53:57 | lyarwood | and the last I checked it was still clean | |
| 13:53:59 | lyarwood | just | |
| 13:54:02 | efried | orly? | |
| 13:54:21 | lyarwood | yeah I know right | |
| 13:54:23 | efried | I thought I'd seen a bunch of twiddling of test_driver that seems unavoidable considering how many places you hit | |
| 13:55:29 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/stein: libvirt: Use SATA bus for cdrom devices when using Q35 machine type https://review.opendev.org/663677 | |
| 13:55:32 | lyarwood | ^ just to show I'm not making it up | |
| 13:57:13 | stephenfin | lyarwood: comments incoming on that, btw | |
| 13:57:16 | stephenfin | efried: too | |
| 13:57:21 | lyarwood | stephenfin: thanks | |
| 13:59:19 | stephenfin | lyarwood: done | |
| 13:59:54 | stephenfin | Apologies if you explored that idea already but I couldn't see any comments suggesting it | |
| 14:01:11 | openstackgerrit | Arnaud Morin proposed openstack/nova master: Refresh instance network info on deletion https://review.opendev.org/660761 | |
| 14:02:05 | efried | lyarwood: It's early, but I think you changed the logic of the extracted method. | |
| 14:07:37 | gibi | exit | |
| 14:08:05 | dansmith | no | |
| 14:09:33 | gibi | :) | |
| 14:09:33 | efried | you can check out any time you like, | |
| 14:09:34 | efried | but you can never leeeeaaave | |
| 14:09:34 | gibi | sorry | |
| 14:10:07 | dansmith | efried: kinda infringing on mriedem's turf there buddy | |
| 14:10:15 | gibi | stephenfin: which test case was too brittle to change in https://review.opendev.org/#/c/660774 ? | |
| 14:11:10 | stephenfin | gibi: | |
| 14:11:11 | stephenfin | * tbachman (~tbachman@128.107.241.188) has joined #openstack-nova | |
| 14:11:11 | stephenfin | <efried> lyarwood: It's early, but I think you changed the logic of the extracted method. | |
| 14:11:11 | stephenfin | * ttsiouts has quit (Remote host closed the connection) | |
| 14:11:11 | stephenfin | * brault (~brault@lfbn-1-9197-156.w86-238.abo.wanadoo.fr) has joined #openstack-nova | |
| 14:11:12 | stephenfin | * ttsiouts (~ttsiouts@2001:1458:204:1::101:9145) has joined #openstack-nova | |
| 14:11:18 | stephenfin | damn you HexChat | |
| 14:11:27 | stephenfin | gibi: https://review.opendev.org/#/c/660774/3/nova/tests/unit/compute/test_compute.py@12875 | |
| 14:11:49 | tbachman | stephenfin: accidental beep? | |
| 14:12:04 | stephenfin | tbachman: Yup. Sorry for the noise | |
| 14:12:04 | lyarwood | efried: yeah you're right but I'm not sure the original logic was there tbh | |
| 14:12:08 | tbachman | no worries! | |
| 14:12:18 | lyarwood | efried: that seems to suggest that the config would overwrite the image metadata | |
| 14:12:54 | lyarwood | efried: shouldn't it be (mach_type or libvirt_utils.get_default_machine_type(caps.host.cpu.arch))? | |
| 14:13:03 | efried | lyarwood: No, the image meta took first priority, then the config, then the caps (IIUC) | |
| 14:13:21 | lyarwood | ah that diff was all messed up on my screen | |
| 14:13:23 | efried | I don't know what it *should* be. I'm just parsing what it *was* vs what it is in your patch. | |
| 14:13:29 | lyarwood | ack thanks | |
| 14:15:16 | efried | if image_meta... is not None: | |
| 14:15:16 | efried | mach_type = image_meta... | |
| 14:15:16 | efried | ==> and the rest of the logic was in the `else`, so would be skipped and we go right to the return | |
| 14:16:21 | lyarwood | yup sorry the indentation was all messed up in gerrit so I missed that before | |
| 14:16:41 | efried | in the `else` we did: | |
| 14:16:41 | efried | if caps.onething: | |
| 14:16:41 | efried | mach_type = onething | |
| 14:16:41 | efried | if caps.anotherthing | |
| 14:16:41 | efried | mach_type = anotherthing | |