| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-06 | |||
| 09:04:15 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: re-calculate provider mapping during migration https://review.opendev.org/655112 | |
| 09:04:16 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth https://review.opendev.org/655109 | |
| 09:04:16 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle migrations https://review.opendev.org/655114 | |
| 09:04:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: func test for migrate server with ports having resource request https://review.opendev.org/655113 | |
| 09:07:30 | openstackgerrit | Alvaro Lopez Garcia proposed openstack/nova master: Ensure that periodic reclaim cleans DB deleted instances https://review.opendev.org/323250 | |
| 09:09:43 | bauzas | lyarwood: FWIW, I'm categorizing https://bugs.launchpad.net/nova/+bug/1831538 as High since 'q35' isn't the gate default machine type | |
| 09:09:45 | openstack | Launchpad bug 1831538 in OpenStack Compute (nova) "IDE config drive CDROM doesn't work with q35 machine type" [High,In progress] - Assigned to Lee Yarwood (lyarwood) | |
| 09:10:13 | lyarwood | bauzas: ack that's fair | |
| 09:10:26 | bauzas | lyarwood: but if we consider 'q35' to be more useful to our users than 'pc', I think https://review.opendev.org/#/c/662887/ is much appreciated | |
| 09:11:01 | kashyap | bauzas: It's not necessarily "more useful"; in some cases 'pc' chipset maybe what the user precisely wants | |
| 09:11:02 | lyarwood | bauzas: yeah I spoke to artom yesterday about potentially dropping DNM from that | |
| 09:11:19 | bauzas | lyarwood: https://review.opendev.org/#/c/662887/ is still getting -1 from Zuul | |
| 09:11:27 | lyarwood | bauzas: it's an unrelated failure | |
| 09:11:34 | kashyap | bauzas: But in general, for new guests, we recommend 'q35'. | |
| 09:11:35 | lyarwood | bauzas: I rechecked this morning | |
| 09:12:01 | bauzas | oh sorry | |
| 09:12:45 | bauzas | kashyap: yeah i don't disagree, that's why we leave machine types to be configurable | |
| 09:13:14 | bauzas | kashyap: here I'm talking of choosing a default value for most users, and it looks to me 'q35' gives more benefits than 'pc' | |
| 09:13:32 | bauzas | so, technically, we should have it in the gate | |
| 09:13:37 | kashyap | Yep; also one reason I avoided changing the default in Nova (https://bugs.launchpad.net/nova/+bug/1780138), because we've delegated that decision to the orchestrator for now. | |
| 09:13:38 | 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) | |
| 09:13:43 | kashyap | [We may revisit it later] | |
| 09:14:04 | kashyap | bauzas: Yeah, agreed -- on testing in Gate. | |
| 09:16:13 | openstackgerrit | Merged openstack/nova master: Document mitigation for Intel MDS security flaws https://review.opendev.org/661574 | |
| 09:35:43 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Add flavor metadata or metadata group https://review.opendev.org/663563 | |
| 09:37:33 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Add flavor metadata or metadata group https://review.opendev.org/663563 | |
| 09:47:43 | openstackgerrit | Dongcan Ye proposed openstack/nova master: Raise BuildAbortException while updating instance task_state conflict https://review.opendev.org/633160 | |
| 10:34:39 | openstackgerrit | Sharat Sharma proposed openstack/nova master: "SUSPENDED" description changed in server_concepts guide and API REF https://review.opendev.org/663590 | |
| 10:53:17 | mdbooth | lyarwood: Re: https://review.opendev.org/#/c/663596/ has that test ever worked? | |
| 10:53:40 | mdbooth | I mean, it sorta worked, but only because we weren't doing image validation, right? | |
| 10:55:27 | lyarwood | mdbooth: correct | |
| 10:56:28 | lyarwood | mdbooth: so that change disables it by default and leaves some configurables we can wire up over in https://review.opendev.org/#/c/515210/ if we wanted to | |
| 10:58:10 | lyarwood | mdbooth: just respinning to make the requirements more clear and link https://review.opendev.org/#/c/515210/ in the commit message | |
| 10:58:53 | mdbooth | lyarwood: Even with that change though, the test is still broken right? | |
| 10:59:17 | mdbooth | Because if the image has been previously cached by another test it won't actually run. | |
| 10:59:19 | lyarwood | mdbooth: if a valid image and trusted certs are provided then no | |
| 10:59:22 | mdbooth | s/run/validate/ | |
| 10:59:39 | lyarwood | mdbooth: it's no longer using the default image that wouldn't work | |
| 10:59:40 | mdbooth | It will pass, but it won't have tested image validation. | |
| 10:59:55 | mdbooth | Ah... you also updated the ref | |
| 10:59:58 | lyarwood | mdbooth: it should | |
| 11:00:00 | lyarwood | yeah | |
| 11:00:03 | lyarwood | it should cause a download etc | |
| 11:00:17 | mdbooth | lyarwood: Sorry, was being sloppy didn't read that far. | |
| 11:00:23 | lyarwood | the test isn't specifically looking at that btw | |
| 11:00:32 | lyarwood | that's more to just avoid failures | |
| 11:00:46 | lyarwood | the barbican plugin is really testing all of that | |
| 11:00:51 | openstackgerrit | Sharat Sharma proposed openstack/nova master: [Docs] Update the confusing console output https://review.opendev.org/589004 | |
| 11:22:40 | kashyap | sean-k-mooney: So, for the PCIe root ports, default to 32 / max 32 -- yeah? Based on DanPB's tests? | |
| 11:23:17 | sean-k-mooney | yes | |
| 11:27:21 | kashyap | Thx | |
| 11:28:49 | openstackgerrit | Edward Hope-Morley proposed openstack/nova master: Fix python3 compatibility of rbd get_fsid https://review.opendev.org/663607 | |
| 11:49:39 | kashyap | git fetch gerrit | |
| 11:50:04 | kashyap | Oops | |
| 11:50:17 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: [WIP] libvirt: Update the default number of PCIe root ports to 32 https://review.opendev.org/663614 | |
| 11:50:33 | kashyap | sean-k-mooney: ^ Still need to reword the commit, and tweak the test, perhaps | |
| 11:50:42 | kashyap | (And also to see if any other code path is effected) | |
| 11:54:38 | sean-k-mooney | kashyap: ya just commented on the test you should leave it at 8 as you are testing non defualt config values | |
| 11:55:42 | kashyap | sean-k-mooney: Yeah, you're right. (Aside: Instead of "Update", I'd use the phrase "Preallocate" -- as that captures the intention more correctly?) | |
| 11:55:57 | kashyap | sean-k-mooney: I stole the preallocate word from you | |
| 11:56:01 | sean-k-mooney | i didnt look into the test fully but i suspect we want to test the default, when its set to 0 and when its set to a non default non 0 values | |
| 11:57:07 | kashyap | Right, let me twiddle | |
| 11:57:36 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/stein: Hide hypervisor id on windows guests https://review.opendev.org/663616 | |
| 11:57:49 | sean-k-mooney | well we are updating the config value to preallocate the pcie-ports so tehy are availabel for hotplug when needed | |
| 11:58:54 | kashyap | (Nod) | |
| 12:06:02 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Fix python3 compatibility of rbd get_fsid https://review.opendev.org/635220 | |
| 12:07:23 | lyarwood | mdbooth: ^ FYI just stumbled across this | |
| 12:09:38 | mdbooth | lyarwood: Interesting. I wonder why we haven't hit that, yet. | |
| 12:10:24 | artom | lyarwood, yeah, a ML post needs to happen about that | |
| 12:10:30 | artom | (that = q35) | |
| 12:14:28 | mdbooth | lyarwood: I wonder if we've already pulled in the ceph fix downstream? | |
| 12:14:42 | kashyap | artom: I have a half draft sitting; will send something "soon" | |
| 12:14:55 | kashyap | artom: Based on the description notes here: https://bugs.launchpad.net/nova/+bug/1780138 | |
| 12:14:55 | artom | kashyap, appreciated :) | |
| 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: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:06 | kashyap | 13:23 < hrw> 29 == uefi dumps to shell instead of booting | |
| 12:53:06 | kashyap | 13:23 < hrw> ok. 28 pcie-root-port entries are maximum | |
| 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 | sean-k-mooney | ok so we should leave it at 28 and just set teh default to 28 | |
| 12:53:40 | kashyap | [That snippet is from Feb 2018, BTW] | |
| 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 | |