| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-04 | |||
| 09:40:26 | Jorhson | lyarwood: yeah, this is conflicting | |
| 09:40:54 | lyarwood | Jorhson: this all comes down to the RPC call to reservice_block_device_name | |
| 09:41:38 | lyarwood | Jorhson: and I honestly think we can just drop device_name from the APIs and remove this, again with a microversion | |
| 09:42:03 | Jorhson | lyarwood: but i also think it's need for this options, because attaching volume is independent option | |
| 09:42:25 | lyarwood | Jorhson: true but that's why we queue things in the compute with the various locks | |
| 09:43:01 | Jorhson | lyarwood: there will be conflicting if we do others task while the attching task is not over | |
| 09:43:02 | lyarwood | Jorhson: we'd be changing the semantics of the API here pretty drastically and forcing the callers to retry by introducing these task_states | |
| 09:43:22 | brinzhang_ | jorhson: agree with lyarwood, add a microversion to remove the device, and in order to avoid the conflict, we also need to add the task_state as current description in your spec | |
| 09:43:47 | lyarwood | well we have the instance.uuid lock to avoid conflicts | |
| 09:44:03 | lyarwood | most compute operations should be taking that IMHO | |
| 09:44:15 | lyarwood | I know it's not the case for everything at the moment | |
| 09:46:33 | lyarwood | so what if we didn't reject the request if the task_state was attaching and queued it in the API somehow? | |
| 09:46:39 | lyarwood | Jorhson / brinzhang_ ; ^ | |
| 09:47:46 | Jorhson | lyarwood: yeah, for the users, there are less probability to attach multiple volumes, and i agree with your sheme, but i think it's important to solve the option's conflict | |
| 09:48:18 | lyarwood | Jorhson: it's a pretty common usecase with k8s running on OpenStack IMHO | |
| 09:54:38 | brinzhang_ | lyarwood: ok, I understand what you mean, agree | |
| 09:55:28 | brinzhang_ | lyarwood: Jorhson will update this spec later, this way it's better for k8s on OpenStack scenario | |
| 09:59:36 | lyarwood | brinzhang_: ack many thanks both, I'm going to be AFK again this afternoon UK time but I'll review the spec this evening once I'm back. | |
| 10:00:34 | brinzhang_ | lyarwood: ack, thanks too | |
| 10:01:52 | aarents | Hi nova | |
| 10:02:22 | openstack | Launchpad bug 1832248 in OpenStack Compute (nova) "tempest.api.volume.test_volumes_extend.VolumesExtendAttachedTest.test_extend_attached_volume failing when using the Q35 machine type" [Medium,Triaged] - Assigned to Alexandre arents (aarents) | |
| 10:02:22 | aarents | lyarwood: there is some progress on that q35 bug: https://bugs.launchpad.net/nova/+bug/1832248 , if it is a qemu bug, what is the suitable status for this bug Fixed_in_relsease or invalid? | |
| 10:07:26 | lyarwood | aarents: awesome sleuthing! :) | |
| 10:08:04 | lyarwood | aarents: erm, invalid I guess? gibi ^ any thoughts, looking to close a Nova bug that was actually a QEMU bug that has already been fixed | |
| 10:09:11 | gibi | lyarwood: if it is fixed in QEMU and no need for any nova change then Invliad it is | |
| 10:09:20 | gibi | Invalid even | |
| 10:09:25 | lyarwood | cool thanks | |
| 10:15:38 | aarents | cool, I just hope it will fix also my downstrem bug regarding interface attach! | |
| 11:56:55 | sean-k-mooney | do we need to enable the new qemu from the cloud arcive on ussuri and below to ensure we dont hit that bug | |
| 12:04:23 | openstackgerrit | Wenping Song proposed openstack/nova-specs master: Support vGPU management by Cyborg https://review.opendev.org/750116 | |
| 13:04:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Prevent starting services with older than N-1 computes https://review.opendev.org/738482 | |
| 13:04:54 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add upgrade check about old computes https://review.opendev.org/760520 | |
| 13:19:50 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Prevent starting services with older than N-1 computes https://review.opendev.org/738482 | |
| 13:21:15 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add upgrade check about old computes https://review.opendev.org/760520 | |
| 13:23:41 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use _evacuate_server helper in func test https://review.opendev.org/758210 | |
| 13:27:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ignore PCI devices with 32bit domain https://review.opendev.org/756697 | |
| 13:27:17 | openstack | bug 1897528 in OpenStack Compute (nova) "32bit pci domain number is not supported" [High,In progress] https://launchpad.net/bugs/1897528 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 13:27:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1897528 https://review.opendev.org/756696 | |
| 13:36:47 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Support interface attach with qos ports https://review.opendev.org/755477 | |
| 14:03:43 | openstack | bug 1896463 in OpenStack Compute (nova) rocky "evacuation failed: Port update failed : Unable to correlate PCI slot " [Low,In progress] https://launchpad.net/bugs/1896463 | |
| 14:03:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1896463 in func env https://review.opendev.org/754100 | |
| 14:05:10 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Set instance host and drop migration under lock https://review.opendev.org/754815 | |
| 14:07:17 | openstack | bug 1896463 in OpenStack Compute (nova) rocky "evacuation failed: Port update failed : Unable to correlate PCI slot " [Low,In progress] https://launchpad.net/bugs/1896463 | |
| 14:07:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1896463 in func env https://review.opendev.org/754100 | |
| 14:08:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Set instance host and drop migration under lock https://review.opendev.org/754815 | |
| 14:51:12 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add upgrade check about old computes https://review.opendev.org/760520 | |
| 15:02:45 | openstackgerrit | Takashi Natsume proposed openstack/nova stable/victoria: Fix a hacking test https://review.opendev.org/758112 | |
| 15:05:44 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/victoria: [doc]: Fix glance image_metadata link https://review.opendev.org/761423 | |
| 15:07:10 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/victoria: Use cell targeted context to query BDMs for metadata https://review.opendev.org/761424 | |
| 15:29:19 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Bump the lowest eventlet version to 0.26.1 https://review.opendev.org/761427 | |
| 15:55:10 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: [trivial]: replace NUMNA with NUMA https://review.opendev.org/761436 | |
| 16:19:43 | openstackgerrit | Merged openstack/nova-specs master: [trivial]: replace NUMNA with NUMA https://review.opendev.org/761436 | |
| 16:26:56 | openstack | Launchpad bug 1902276 in OpenStack Compute (nova) "libvirtd going into a tight loop causing instances to not transition to ACTIVE" [Undecided,New] | |
| 16:26:56 | gibi | somebody with connection to the libvirt maintainer should look at this nova bug https://bugs.launchpad.net/nova/+bug/1902276 | |
| 16:28:04 | melwitt | kashyap: ^ | |
| 16:28:26 | kashyap | melwitt: Yeah, familar with it, as I worked with the reporter here the other day | |
| 16:28:39 | melwitt | ah ok, cool | |
| 16:28:43 | kashyap | melwitt: I asked one of the libvirt devs on Friday, but my timing wasn't right | |
| 16:28:52 | gibi | kashyap: thanks! | |
| 16:28:57 | kashyap | I'll check again | |
| 16:29:18 | kashyap | gibi: It looks fishy, as it's not 100% reproducible ... as the reporter says "a few minutes later things go back to normal" | |
| 16:29:26 | kashyap | But we don't know what changed :-( | |
| 16:31:47 | gibi | kashyap: the nova image download take ~ 300 seconds for the VM that then triggers the loop in libvirtd so it might be that the hypervisor host has high load | |
| 16:31:57 | kashyap | gibi: Yeah, just reading your report :) | |
| 16:31:58 | gibi | but I was not able to confirm it from the logs | |
| 16:33:13 | kashyap | I see. Hypervisor load sounds plausible - as we've hit load-related (CI) issues libvirt driver before. But still let me check w/ Dan or someone from upstream libvirt | |
| 16:34:25 | gibi | kashyap: thanks for taking this up with the libvirt maintainers | |
| 16:35:34 | kashyap | gibi: Just posted on #virt, OFTC network. | |
| 16:36:18 | kashyap | gibi: Is this blocking patch merges? | |
| 16:39:05 | melwitt | I've been struggling for a couple of days trying to get an approved patch through the gate, but I'm not sure whether that particular bug is involved. I would need to re-look at the logs to verify | |
| 16:39:25 | kashyap | (I've reposted the looping libvirtd log bits as a plain text, as the pastebins expire) | |
| 16:40:58 | kashyap | melwitt: Noted; Michael, the reporter, was saying on last Friday that it's "intermittent", which makes it a bit more difficult to debug | |
| 16:41:56 | melwitt | yeah, that's been the theme of all of the gate bugs I'm aware of. intermittent and thus hard to troubleshoot :( | |
| 16:42:06 | melwitt | *current gate bugs I'm aware of | |
| 16:43:01 | kashyap | Yeah, matches my past experience | |
| 16:43:53 | kashyap | melwitt: In the same vein as how Twitter (I'm not on it) seems to label Trump's tweets as misleading, wonder we should adapt that text for these intermittent bugs :D | |
| 16:44:26 | kashyap | - Some or all of the content shared in this Tweet is disputed and might be misleading about an election or other civic process. | |
| 16:44:29 | kashyap | + Some or all of the content shared in this bug is disputed and might be misleading due to intermittent failures. | |
| 16:46:02 | kashyap | gibi: melwitt: More seriously, can I "subscribe" (Cc) someone else to a LaunchPad, right? | |
| 16:46:21 | kashyap | IIRC, yes. /me tries | |
| 16:46:26 | melwitt | I think you can | |
| 16:48:11 | kashyap | melwitt: I can't :-( I wanted to Cc Michal from libvirt but it says "No items matched <email ID>" | |
| 16:48:44 | melwitt | do you know his launchpad id? | |
| 16:48:55 | kashyap | melwitt: Oh, having a Launchpad ID is mandatory? | |
| 16:49:19 | melwitt | it might be, that's the only way I've seen subscribing | |
| 16:50:44 | kashyap | Ah, noted. I don't think he has one - searching doesn't show up anything. | |
| 16:51:41 | kashyap | melwitt: I pointed to him on IRC; he's taking a look | |
| 16:53:00 | melwitt | thanks! | |
| 16:55:23 | kashyap | melwitt: gibi: That's quick -- Michal (Privoznik) says it looks like a genuine bug. I'll update the bug once we get more details | |
| 16:56:35 | melwitt | sounds great, thank you kashyap | |
| 17:06:24 | kashyap | melwitt: So, the libvirt version in the logs above is 5.4.0; but havne't we switche dalready to libvirt-6.0.0? | |
| 17:06:39 | kashyap | lyarwood: --^ (By "we", I mean upstream CI) | |
| 17:08:11 | kashyap | So Michal says, there were improvements in libvirt-6.1.0 release on this area of event loops. | |
| 17:13:52 | stephenfin | lyarwood: Could you cast an eye over https://review.opendev.org/#/c/631053/ this evening, please? | |
| 17:14:04 | stephenfin | It's been around for quite a while :-D | |
| 17:18:01 | mloza | hello, is it possible to update the video model to vmga of an existing instance? | |
| 17:19:11 | mloza | if i edit /etc/libvirt/qemu/instance-, it reverts to default when the instance is hard rebooted | |
| 17:20:04 | stephenfin | mloza: Outside of rebuilding to a new image, no. We don't support setting it via the flavor so resize isn't an option | |
| 17:21:47 | stephenfin | mloza: You'll have to modify the DB manually if you want to avoid the rebuild | |
| 17:22:18 | mloza | can you tell me which table do I need modify | |