| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-02 | |||
| 17:54:21 | sean-k-mooney | https://github.com/openstack/nova/commit/eae37a27caa5ca8b0ca50187928bde81f28a24e1#diff-91f79786d7e3744c39926c88bbafe3b727630fa4eb48e845686d7f12f876d067L531 | |
| 18:05:02 | openstackgerrit | Merged openstack/nova master: Docs: Correct ``Password injection using the dashboard`` Explanation https://review.opendev.org/c/openstack/nova/+/775084 | |
| 18:09:53 | dansmith | sean-k-mooney: we only ever drop params in a major bump, and all such bumps have dropped parameters, AFAIR | |
| 18:10:31 | dansmith | sean-k-mooney: you need to continue to honor them for N-1.x compatibility in that shim, but the N.0 client and server can assume everything is always passed and expected at the new signatures you want going forward | |
| 18:11:05 | sean-k-mooney | dansmith: yes that is what i understood too | |
| 18:11:09 | dansmith | ack | |
| 18:15:44 | dansmith | bauzas: to be clear, we do not need to do any sort of "deprecate in 6.x and remove in 7.0" dance for _anything_. We're the only consumer of this API, so we only need to make sure we honor our own rules.. | |
| 18:16:08 | dansmith | The entire 5.x lineage is adding things to the API as optional, to be made mandatory in 6.0, and ignoring things we plan to drop in 6.0 | |
| 18:16:52 | dansmith | so all you need to do is support 5.max and 6.0 in both the client and server, and the only thing that you can't do is break 5.max.. 6.0 could be anything else you want if you're willing to make the changes | |
| 18:19:06 | bauzas | dansmith: ok, I'll see what I can do | |
| 18:19:20 | bauzas | the 6.0 bump already has a long list of changed things | |
| 18:19:28 | bauzas | and I'm just about cleaning it more | |
| 18:19:42 | bauzas | I'm the janitor and it's a mess | |
| 18:19:59 | dansmith | that's the whole point of a major bump though | |
| 18:20:09 | bauzas | I don't disagree | |
| 18:20:14 | dansmith | it's both why we should maybe do it more frequently, and also why we don't :) | |
| 18:20:41 | bauzas | I'm just afraid by the timings here | |
| 18:20:45 | bauzas | and the review steam | |
| 18:21:00 | dansmith | yup, it's hard, and why we've been talking about it for a cycle :) | |
| 18:21:38 | bauzas | Zuul eventually gave me its blessing after a long period of doubt | |
| 18:22:04 | bauzas | and I'm just removing extra other bits | |
| 18:24:00 | bauzas | but OK, I can try | |
| 18:43:59 | openstackgerrit | Stephen Finucane proposed openstack/python-novaclient master: WIP: Add support for setting VNC password https://review.opendev.org/c/openstack/python-novaclient/+/778229 | |
| 18:45:39 | stephenfin | melwitt: More comments on https://review.opendev.org/c/openstack/nova/+/622336 | |
| 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 | |