| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-02 | |||
| 18:45:49 | stephenfin | I'm so confused about what's doing what | |
| 18:48:04 | stephenfin | melwitt: At present, it seems totally broken but there's a good chance I'm misunderstanding something. If so, or if I'm saying daft things, please let me know :) | |
| 18:55:55 | bauzas | dansmith: around ? I'm facing some concern about https://review.opendev.org/c/openstack/nova/+/761452/9/nova/tests/functional/libvirt/test_numa_live_migration.py | |
| 18:56:19 | bauzas | since we upgraded to 6.0, now the version_cap is defaulted to 6.0 | |
| 18:56:42 | bauzas | and then can_send_version() can only support 6.0 | |
| 18:57:01 | bauzas | while previously with 5.13, can_support_version was accepting 5.3 | |
| 18:57:13 | bauzas | even if the version cap was 5.13 | |
| 18:57:48 | bauzas | what should I do ? stick with what I wrote, or stub the RPC API for a 5.13 version cap ? | |
| 18:58:00 | bauzas | (even if we don't pin) | |
| 18:58:39 | bauzas | this whole testclass is so tangled with RPC versioning that we should consider axing a lot of them later on | |
| 18:58:48 | bauzas | but I just want to pass the bar here | |
| 18:59:09 | bauzas | and not do unnecessary scrubbing | |
| 19:02:46 | bauzas | actually, I need to eat by now | |
| 19:16:35 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452 | |
| 19:41:38 | openstackgerrit | Merged openstack/nova master: libvirt: allow querying devices from the persistent domain https://review.opendev.org/c/openstack/nova/+/772383 | |
| 20:18:18 | dansmith | bauzas: I think those tests were doing exactly what they needed, and I remember all the work artom did to make them validate all the upgrade concerns | |
| 20:19:02 | dansmith | bauzas: I think a lot of the concern there goes away with 6.0, but it might be best to pin them to their original versions (i.e. pretend they're running in an upgrade scenario) until we can drop 5.x | |
| 20:19:48 | bauzas | so, which option would you prefer ? | |
| 20:20:08 | bauzas | scenario 2 in my comment, ie. capping to 5.13 ? | |
| 20:20:17 | bauzas | dansmith: ^ | |
| 20:20:28 | bauzas | or scenario 1, leave as it is | |
| 20:20:57 | bauzas | from what I understand you, looks like you prefer scenario #2 | |
| 20:35:57 | dansmith | bauzas: commented | |
| 20:36:40 | bauzas | ta, will look | |
| 20:39:42 | bauzas | dansmith: ok thanks, will then pin to 5.13 | |
| 20:39:51 | dansmith | cool | |
| 21:27:22 | bauzas | g'night | |
| 21:43:13 | openstackgerrit | Merged openstack/nova master: apidb: Compact Newton database migrations https://review.opendev.org/c/openstack/nova/+/759401 | |
| #openstack-nova - 2021-03-03 | |||
| 00:54:18 | openstackgerrit | sean mooney proposed openstack/nova master: add hw:mlock extra spec https://review.opendev.org/c/openstack/nova/+/778347 | |
| 02:24:47 | openstackgerrit | sean mooney proposed openstack/nova master: add vdpa vnic to pci request mapping and filtering. https://review.opendev.org/c/openstack/nova/+/778350 | |
| 07:06:48 | songwenping__ | melwitt: hi, your process is right, the guest xml is live update but it doesnot work unless we reboot the guest. this is really a problem. | |
| 08:08:43 | brinzhang | gibi, bauzas: replied in https://review.opendev.org/c/openstack/nova/+/761452/9/nova/compute/manager.py#2101 | |
| 08:09:10 | brinzhang | gibi, bauzas: do I need to register a bug, then submit the fix? | |
| 08:26:44 | bauzas | brinzhang: good afternoon for you | |
| 08:27:16 | brinzhang | bauzas: good morning^ | |
| 08:27:46 | bauzas | brinzhang: yes, please file a bug and work on a patch if you want to fix it | |
| 08:28:21 | brinzhang | bauzas: ack, I will file a bug, then fix it with a seperate patch | |
| 08:28:28 | bauzas | thanks | |
| 08:28:46 | bauzas | brinzhang: then, ping me | |
| 08:28:58 | brinzhang | bp, thanks point this bug, this is my ignore | |
| 08:29:04 | bauzas | and I'll see whether I can rebase my RPC API change above your change | |
| 08:29:25 | brinzhang | bauzas: ack, cool | |
| 08:29:28 | bauzas | because if not, you couldn't backport it to stable | |
| 08:29:48 | brinzhang | yeah | |
| 08:43:01 | gokhani | Hi folks, ı have a development environment which is installed by OSA Ussuri. ı have problems on nova-api side. I can observe rabbitmq timeout errors > http://paste.openstack.org/show/803175/ and rarely I am getting connection failed errors to rabbitmq on api side > http://paste.openstack.org/show/803176/. And ıt is strange behaviour now we don't | |
| 08:43:02 | gokhani | have any uwsgi processes on nova api side. I doubt about uwsgi + nova. this is expected behaviour or there is a problem on nova, I am not sure. do you have any ideas about this ? nova = 21.1.1 and oslo.messaging version is 12.1.4 | |
| 08:57:55 | kashyap | stephenfin: gibi: Morning; I was away earlier yesterday. Reading the scroll; I see your question is answered on the +/- thing | |
| 08:58:34 | kashyap | gibi: Indeed; thanks for the ACK; the separate options would've made sense if we were doing it from scratch. | |
| 08:59:31 | kashyap | Thanks for bearing with me. | |
| 09:35:39 | songwenping__ | stephenfin: morning; there are two problems for the noVNC patch. 1. the password works after you reboot the guest 2. if you donnot pass the password when get-vnc-console, you need config `[vnc]auth_schemes = none, vnc` in /etc/nova/nova-cell1.conf for noVNC guest. | |
| 09:38:53 | songwenping__ | for the first issue, we can clarify in the docs that user need to reboot the server if set/reset password for vnc console. we can improve if the libvirt/qemu support live set/reset password. | |
| 09:41:47 | stephenfin | songwenping__: to be honest, it sounds like we shouldn't allow users to change the password if that's not supported so | |
| 09:41:59 | stephenfin | I don't think asking users to restart their instance is a reasonable request | |
| 09:44:25 | openstackgerrit | Lucas Alvares Gomes proposed openstack/nova master: [OVN] Explicitly set nova-next job to ML2/OVS https://review.opendev.org/c/openstack/nova/+/776944 | |
| 09:44:26 | songwenping__ | for the second issue, we plan to update the release note and the description of nova/conf/vnc.py for `auth_schemes`. | |
| 09:46:04 | songwenping__ | stephenfin: the libvirt docs[1] said it already support live update password, but i donnot know why it failed in my local ven. [1] https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainUpdateDeviceFlags | |
| 09:55:07 | brinzhang | stephenfin, songwenping__:IMHO, support reset VNC password is good for the user, it can be protected thire instance opening by unknown user, if it must be reboot to take effect, can we do the first mode to support [vnc]auth_schemes=vnc? | |
| 09:59:00 | lyarwood | stephenfin / gibi ; https://review.opendev.org/c/openstack/nova/+/778177 should be good now btw, I missed that the requirements job actually forces you to sync the in-direct LC deps to requirements that bloats the change a little | |
| 09:59:07 | stephenfin | brinzhang: The issue is that _set_ VNC password also requires a reboot | |
| 09:59:19 | lyarwood | as discussed with sean-k-mooney yesterday I've added a note to the PTG to discuss this mess | |
| 09:59:35 | stephenfin | Basically to touch anything to do with VNC passwords, the instance must be restarted | |
| 10:05:37 | brinzhang | stephenfin: can you check this libvirt docs? https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainUpdateDeviceFlags does it means it cannot be reset password if flags=LIVE(1)? | |
| 10:06:31 | brinzhang | *E.g. the hypervisor driver will return failure if LIVE is specified but it only supports modifying the persisted device allocation.*, so the VNC password isnot blongs to the *persisted device*? | |
| 10:09:36 | songwenping__ | stephenfin: we just need reboot first time to set password, if we reset the password again, we donnot need reboot the server any more. | |
| 10:10:03 | gibi | brinzhang: I agree to have a bug reported and fixing it in a separate patch | |
| 10:10:19 | songwenping__ | from none -> vnc need to reboot, from vnc -> vnc donnot need to reboot | |
| 10:11:29 | brinzhang | gibi: I have filed the bug, and will be submited the fix later ^, pls see bug 1917592 | |
| 10:11:32 | openstack | bug 1917592 in OpenStack Compute (nova) "Missed 'accel_uuids' when we the 'shelved_offload_time' time out in shelving instance periodic task" [Medium,New] https://launchpad.net/bugs/1917592 - Assigned to Brin Zhang (zhangbailin) | |
| 10:11:37 | gibi | brinzhang: thanks | |
| 10:11:56 | brinzhang | gibi: np, thanks for your mind too | |
| 10:13:13 | gibi | lyarwood: thanks I] | |
| 10:13:17 | gibi | lyarwood: thanks I'm +2 | |
| 10:19:45 | lyarwood | cheers | |
| 10:22:18 | lyarwood | random question, does anyone know why we don't use the instance UUID as the domain name within libvirt? | |
| 10:22:48 | lyarwood | trying to debug a live migration failure on stable/ussuri and hate having to lookup the domain name in the logs | |
| 10:26:29 | gibi | lyarwood: good question, we probably need a historian to answer itr | |
| 10:28:06 | kashyap | Yeah, I don't remember that answer either; and wondered the same in the past | |
| 10:28:26 | kashyap | But the guest XML records both instance-YYYYYYY and the UUID | |
| 10:28:46 | stephenfin | brinzhang: Yeah, looking now | |
| 10:30:10 | stephenfin | brinzhang: songwenping__: IMO we need to fix this and figure out how to get VNC password working with TLS. At the moment, enabling this means (a) no TLS, (b) you have to restart the instance to use the feature, and (c) you have to do some funky nova.conf changes for things to work | |
| 10:30:35 | stephenfin | Also (d) you're stuck with 8 characters (not our fault, but unfortunate all the same) | |
| 10:30:43 | stephenfin | Not a good UX /o\ | |
| 10:31:39 | stephenfin | brinzhang: I know it's a lot of work that you said you don't want to do it, but I would still seriously suggest switching the order of the VNC password and tenant_id -> project_id series | |
| 10:32:01 | lyarwood | kashyap: yeah thats fine in live envs, just a PITA when you only have logs to debug things | |
| 10:32:15 | lyarwood | kashyap: I think it might be that libvirt couldn't fit the entire UUID in the name or something? | |
| 10:32:18 | kashyap | lyarwood: Yeah, no denying; I just let the steam out by cussing | |
| 10:32:52 | kashyap | lyarwood: Hmm, that I don't remember. But lemme quickly test by creating a domain name with the UUID :) | |
| 10:33:27 | stephenfin | The VNC series is at huge risk due to all those concerns. I can't in good faith merge what I consider to be a broken feature :-( Hopefully we can address them before feature freeze but it will prevent the other series landing until we do | |
| 10:34:38 | kashyap | lyarwood: Ah, so: libvirt seems to be smart here: | |
| 10:34:53 | lyarwood | aaaaaaaaaah it's instance.name | |
| 10:35:17 | kashyap | lyarwood: When I tried to live-modify a guest's name from s/cvm1/64ba587c-57a7-44c0-94ec-5444e5268c4e/ --> libvirt tells me: "well, the guest already has a UUID" | |
| 10:35:59 | kashyap | I tried removing dashes and plug the dash-less UUID into <name/>, it still detects. | |
| 10:36:05 | lyarwood | okay, we can't really change this anyway, it's just annoying | |
| 10:37:08 | kashyap | Yeah, libvirt explicitly rejects a UUID for a domain "name" | |
| 10:37:21 | kashyap | s/Yeah,/Yeah, and/ | |
| 10:38:17 | lyarwood | not sure how we'd do that after the test run | |
| 10:38:56 | kashyap | lyarwood: You mean, you want a file logged a mapping of UUIDs with instance names? | |
| 10:40:11 | lyarwood | yeah but I don't think that's going to be possible *after* tempest has already deleted everything | |
| 10:40:35 | kashyap | Hmm, true | |
| 10:43:51 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: Improve logging https://review.opendev.org/c/openstack/nova/+/778407 | |