| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-04 | |||
| 17:38:04 | sean-k-mooney | os if it was hw_video_model it woudl be img_hw_video_model in the db | |
| 17:38:48 | sean-k-mooney | mloza: were you asking about this on the mailing list too? we basically said the same in our replies | |
| 17:49:45 | bauzas | gibi: stephenfin: fwiw, you accepted a breaking RPC change with https://review.opendev.org/#/c/715326/29/nova/compute/manager.py@3327 by not accepting a nullable accels argument | |
| 17:50:06 | bauzas | sean-k-mooney: ^ | |
| 17:52:41 | bauzas | if a compute client is sending a 5.0 cast to a compute service, then there won't have a accels argument, so the manager will return an exception | |
| 17:56:26 | dansmith | bauzas: good catch | |
| 17:56:39 | dansmith | bauzas: not too late to fix that | |
| 17:57:44 | bauzas | dansmith: I wonder whether we should fix it by the compute v5 proxy I write or having another change we could backport to victoria ? | |
| 17:58:00 | dansmith | bauzas: another change that we backport | |
| 17:58:09 | bauzas | ack, doing it then | |
| 17:58:19 | dansmith | before people try to upgrade to victoria | |
| 17:58:52 | dansmith | technically, this shouldn't be a problem if people upgrade their controllers first, but if they don't, they'll get an explosion that won't be easy to decipher | |
| 17:58:59 | bauzas | yeah | |
| 17:59:01 | dansmith | well, no, actuall,y | |
| 17:59:16 | dansmith | it would blow up for anyone with an old compute if the version is pinned | |
| 17:59:21 | bauzas | given most of the operators upgrade first their conductors, it shouldn't be a problem | |
| 17:59:33 | bauzas | but in case they pin it, yes | |
| 17:59:44 | dansmith | no, because the client was done properly, it will break | |
| 17:59:52 | dansmith | even if they don't pin, assuming they use =auto | |
| 17:59:56 | bauzas | if you pin the API, right? | |
| 18:00:07 | bauzas | why then for auto ? | |
| 18:00:18 | dansmith | the default is =auto, which will select the lowest version supported by all computes, | |
| 18:00:24 | bauzas | ahah | |
| 18:00:32 | dansmith | so if you have one old compute, api, conductor, etc will all choose the older and will not send that argument, | |
| 18:00:33 | bauzas | I see | |
| 18:00:35 | dansmith | and thus it'll explode | |
| 18:00:49 | bauzas | TIL | |
| 18:00:54 | bauzas | about how auto works | |
| 18:00:59 | dansmith | so s/good catch/great catch/ :) | |
| 18:01:21 | dansmith | easy backport to fix it though, luckily, before people start rolling to V | |
| 18:01:28 | bauzas | yup, writing it now | |
| 18:01:36 | bauzas | git stash first tho :) | |
| 18:01:46 | dansmith | heh yeah I bet :) | |
| 18:04:47 | bauzas | dansmith: do we have some documentation about pin=auto ? maybe on your blog ? | |
| 18:04:53 | dansmith | lol | |
| 18:05:07 | dansmith | I guess I didn't think it was really something people often confused | |
| 18:05:25 | dansmith | I'd expect the config doc to be accurate, but let me look | |
| 18:05:53 | bauzas | nevermind, found it ;) https://docs.openstack.org/nova/latest/user/upgrade.html | |
| 18:06:51 | dansmith | the config doc says "don't worry, we'll handle it" without any detail | |
| 18:07:07 | bauzas | yeah, looking at the config option text | |
| 18:07:30 | dansmith | but honestly, | |
| 18:08:00 | dansmith | from the perspective of a deployer, they really just need to know that auto selects the right version, | |
| 18:08:01 | dansmith | without needing to know that our client needs *a* version and not per-target | |
| 18:08:17 | dansmith | we definitely don't want to look up each target's version before *each* call because that would suck | |
| 18:08:22 | bauzas | yeah | |
| 18:08:37 | dansmith | so maybe some developer docs to explain how it actually works, if you think that's important, but ... | |
| 18:08:42 | bauzas | but if we have problem with the default, then that's a high bug for rolling upgrades | |
| 18:09:50 | bauzas | grmblbl, I need to install both python37 and pre_commit module just for a single git commit | |
| 18:10:24 | dansmith | well, | |
| 18:10:33 | dansmith | not just the default, but also if someone were to hand-set the right version | |
| 18:11:28 | bauzas | yup, any rolling upgrade | |
| 18:20:27 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Bump the Compute RPC API to version 6.0 https://review.opendev.org/761452 | |
| 18:27:41 | bauzas | dansmith: triaged https://bugs.launchpad.net/nova/+bug/1902925 lemme say if I told something wrong | |
| 18:27:41 | openstack | Launchpad bug 1902925 in OpenStack Compute (nova) victoria "Upgrades to compute RPC API 5.12 are broken" [Critical,Confirmed] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 18:29:03 | dansmith | bauzas: yep, sounds good.. it makes it sound like the error was combined with the rpc client being right and the server being wrong, | |
| 18:29:13 | dansmith | but even if the client hadn't bumped the version, it would still be wrong | |
| 18:29:17 | dansmith | but yeah, what you said is all right | |
| 18:29:22 | bauzas | ack | |
| 18:29:45 | bauzas | the fix is simple, but I wonder whether we already have a test suite somewhere for it | |
| 18:30:51 | dansmith | well, generally there should be a test to pass the old version and new version of the call, | |
| 18:31:01 | dansmith | but I think it requires adding two test cases, which probably didn't happen | |
| 19:09:46 | bauzas | can anyone know how to get the full stacktrace returned by the API when we have a HTTP500 ? | |
| 19:10:02 | bauzas | I tried with admin rights and I only get the main exception | |
| 19:10:17 | bauzas | ie. OpenStackApiException('Unexpected status code: {"computeFault": {"code": 500, "message": "Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\\n |
|
| 19:10:37 | bauzas | while I would like to see the whole stacktrace | |
| 19:11:33 | bauzas | dansmith: any idea for ^ ? | |
| 19:11:47 | dansmith | that's all we see in the log? | |
| 19:11:51 | bauzas | yup | |
| 19:11:59 | bauzas | I wrote a regression test that works | |
| 19:12:10 | dansmith | I would have thought we log.exception a 500, but I'd guess maybe we've had so many in the past that we had to squelch them | |
| 19:12:21 | bauzas | meh | |
| 19:12:23 | bauzas | anyway | |
| 19:12:37 | bauzas | I'll upload and we could discuss this in the change | |
| 19:13:01 | dansmith | ack | |
| 19:19:19 | dansmith | bauzas: I assume you're just asserting that we get a 500 before the fix and a 2xx after, right? that seems clear enough to me | |
| 19:20:25 | bauzas | dansmith: something like that, yes | |
| 19:20:53 | dansmith | seems fine | |
| 19:21:28 | artom | bauzas, I believe there's precedent for capturing the log and asserting stuff about the content | |
| 19:21:43 | artom | If you want to be really sure you're getting the exact error you expect | |
| 19:23:23 | bauzas | uploading it | |
| 19:23:36 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add a regression test for 5.12 compute API issue https://review.opendev.org/761457 | |
| 19:23:37 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Fix the compute RPC 5.12 issue https://review.opendev.org/761458 | |
| 19:23:48 | bauzas | dansmith: artom: gibi: stephenfin: there it is ^ | |
| 19:24:07 | dansmith | artom: on a functional? | |
| 19:24:20 | artom | dansmith, I'm pretty sure I've seen it done, yeah | |
| 19:24:36 | dansmith | that'd be pretty deep mocking of something that doesn't need to be mocked for behavior | |
| 19:24:53 | dansmith | but even still a 500 that goes to not 500 after the fix seems like plenty to me | |
| 19:25:06 | dansmith | to be clear, I think we need more than just mocking of a log call, | |
| 19:25:18 | dansmith | we need mocking of whatever wraps that exception | |
| 19:25:28 | bauzas | anyway, /me goes off | |
| 19:25:34 | bauzas | 8.25pm here :) | |
| 20:22:02 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Add os-volume_attachments reference docs https://review.opendev.org/760971 | |
| 20:39:47 | openstackgerrit | Billy Olsen proposed openstack/nova stable/ussuri: Set migrate_data.vifs only when using multiple port bindings https://review.opendev.org/759151 | |
| 22:09:35 | openstackgerrit | Billy Olsen proposed openstack/nova stable/train: add functional regression test for bug #1888395 https://review.opendev.org/759533 | |
| 22:09:35 | openstack | bug 1888395 in OpenStack Compute (nova) ussuri "live migration of a vm using the single port binding work flow is broken in train as a result of the introduction of sriov live migration" [High,In progress] https://launchpad.net/bugs/1888395 - Assigned to Billy Olsen (billy-olsen) | |
| #openstack-nova - 2020-11-05 | |||
| 01:09:01 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add os-volume_attachments reference docs https://review.opendev.org/760971 | |
| 01:24:12 | openstackgerrit | MaAoyu proposed openstack/os-traits master: bump py37 to py38 in tox.ini https://review.opendev.org/757432 | |
| 05:43:10 | openstackgerrit | Wenping Song proposed openstack/nova-specs master: Support vGPU management by Cyborg https://review.opendev.org/750116 | |
| 07:47:47 | xinranwang | gibi: Hi gibi, I have replied to your comment about smartnic support, and there are some open question need your suggestion, please check it when you got time. Thanks in advance. https://review.opendev.org/#/c/742785/6/specs/wallaby/approved/support-sriov-smartnic.rst | |
| 08:04:11 | gibi | xinranwang: ack, I will look at it today | |