| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-02-23 | |||
| 16:06:15 | gibi | stephenfin: I did that as a followup for the detach bugfix series | |
| 16:06:53 | stephenfin | gibi++ Yup, realize that. Thanks :) | |
| 16:07:01 | stephenfin | So the unusual thing is the assertion, I assume? | |
| 16:08:54 | stephenfin | gibi: Is it just me, or are all those functions in the exception handlers than are accepting a 'guest' parameter broken? | |
| 16:09:11 | stephenfin | If so, I bet I was the one that broke it too. I recall reworking that stuff recently | |
| 16:09:27 | stephenfin | and attempts to bury the evidence ;) | |
| 16:10:27 | gibi | hm, you have a point, mypy only found the last usage of gues but the expcetion handler code also depends on the guest variable | |
| 16:11:33 | gibi | _cleanup_failed_start checks the guest before use it | |
| 16:11:47 | gibi | so the exception handlers are good | |
| 16:11:58 | stephenfin | the guest is useless though | |
| 16:12:08 | stephenfin | there's no way a function that raises an exception can return something | |
| 16:12:21 | stephenfin | so guest will either always be None or it will be set and an exception won't be raiseed | |
| 16:12:23 | stephenfin | *raised | |
| 16:12:46 | stephenfin | I suspect there was another caller after '_create_guest' previously | |
| 16:12:49 | stephenfin | power on or something | |
| 16:14:05 | gibi | hm, yeah, this can be cleaned up to only run the code that is currently in the finally block of _cleanup_failed_start | |
| 16:15:06 | stephenfin | yeah, https://github.com/openstack/nova/blob/stable/train/nova/virt/libvirt/driver.py#L6351-L6352 | |
| 16:15:55 | stephenfin | there was stuff done after '_create_guest' (formerly '_create_domain') previously | |
| 16:16:20 | stephenfin | so I suspect the real solution to that is to stop passing 'guest' to '_cleanup_failed_start' and remove any code that relied on it? | |
| 16:16:38 | stephenfin | which is what you just said, sorry :) | |
| 16:16:46 | gibi | I don't know why we try to stop the guest | |
| 16:16:57 | gibi | nvm I see it | |
| 16:17:09 | stephenfin | why or where? | |
| 16:17:10 | gibi | so in the past there was a case when the guest was fully started | |
| 16:17:16 | gibi | and then we failed | |
| 16:17:19 | gibi | so we need to stop is | |
| 16:17:20 | gibi | it | |
| 16:17:37 | gibi | but now it either starts without exception or fails before it is started | |
| 16:17:37 | stephenfin | if the firewall driver couldn't apply filters, right? | |
| 16:17:42 | gibi | yepp | |
| 16:17:49 | stephenfin | yeah, that's my reading of this too | |
| 16:18:04 | stephenfin | I did the firewall cleanup too but missed that. Apologies | |
| 16:18:53 | gibi | hm, I don't know what happens if create_guest fails at libvirt_secret.undefine() in the finally block, at that point we have a running guest I assume | |
| 16:19:20 | gibi | but we don't get back the guest object from the caller | |
| 16:19:25 | gibi | to stop it | |
| 16:19:59 | stephenfin | yeah, an exception will still be raised | |
| 16:20:44 | stephenfin | the finally block just executes stuff before the finally happens, iirc | |
| 16:20:52 | stephenfin | akin to save_and_reraise | |
| 16:22:58 | gibi | so we have to catch possible exceptions from libvirt_secret.undefine(), LOG them, and still return the geust object | |
| 16:23:07 | gibi | guest | |
| 16:23:13 | stephenfin | apparently not | |
| 16:23:13 | stephenfin | https://docs.python.org/3/reference/compound_stmts.html#finally | |
| 16:23:22 | stephenfin | If finally is present, it specifies a ‘cleanup’ handler. The try clause is executed, including any except and else clauses. If an exception occurs in any of the clauses and is not handled, the exception is temporarily saved. The finally clause is executed. If there is a saved exception it is re-raised at the end of the finally clause. If the finally clause raises another exception, the saved exception is set as the context of | |
| 16:23:22 | stephenfin | the new exception. If the finally clause executes a return, break or continue statement, the saved exception is discarded: | |
| 16:23:32 | stephenfin | Sorry | |
| 16:23:32 | stephenfin | If the finally clause raises another exception, the saved exception is set as the context of the new exception. | |
| 16:23:49 | stephenfin | so it'll basically do raise undefine_exception from other_exception | |
| 16:24:15 | gibi | yeah that is how I understand | |
| 16:24:48 | stephenfin | yeah http://paste.openstack.org/show/802935/ | |
| 16:25:49 | gibi | if we let the exception propagate from the finally block then we will leave a running guest behind | |
| 16:25:59 | gibi | and the caller cannot stop it | |
| 16:26:08 | gibi | as it has no reference to that guest object | |
| 16:26:26 | stephenfin | Hmm, good point | |
| 16:26:41 | stephenfin | so if the undefine call fails | |
| 16:27:24 | stephenfin | we won't have a running guest before that since launching it is the last thing we do (returning won't cause an exception) | |
| 16:28:47 | gibi | you are right sorry | |
| 16:29:10 | gibi | so no need to change here | |
| 16:33:49 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Follow up type hints for a634103 https://review.opendev.org/c/openstack/nova/+/777159 | |
| 16:44:29 | bauzas | woah, the gate pipeline is late | |
| 16:54:24 | gibi | maybe it is already the churn before the feature freeze | |
| 16:55:11 | stephenfin | bauzas: There are issues. They were discussing it on #openstack-infra earlier | |
| 16:55:19 | stephenfin | Still are, maybe | |
| 16:55:23 | bauzas | kk | |
| 16:55:27 | bauzas | thanks | |
| 17:03:44 | prometheanfire | we're coming up on the end of the release cycle and nova still hasn't fixed mock :| | |
| 17:05:21 | sean-k-mooney | prometheanfire: its not really broken is it. | |
| 17:05:43 | stephenfin | prometheanfire: I thought we'd said that we didn't need to? | |
| 17:06:11 | stephenfin | mock (the third party lib) has fixes that weren't backported to python3.6 | |
| 17:06:43 | stephenfin | and I'm pretty sure the reason mock was capped at <4.0 (iirc) was because that had its own bug | |
| 17:07:26 | stephenfin | prometheanfire: Can you remind me of the reason nova had to switch? I'd stopped focusing on it because working around python3.6 unittest.mock bugs seemed wrong | |
| 17:07:56 | sean-k-mooney | wel should eventulaly swicht to not useing mock the lib at all | |
| 17:08:02 | sean-k-mooney | and use the standard lib only | |
| 17:08:03 | stephenfin | sean-k-mooney: why | |
| 17:08:14 | sean-k-mooney | because mock the lib has some bugs | |
| 17:08:23 | sean-k-mooney | it does not fully work the same as the stanard lib | |
| 17:08:35 | stephenfin | See above | |
| 17:08:41 | prometheanfire | requirements doesn't cap mock | |
| 17:08:48 | sean-k-mooney | and since we are pythoh 3 only now we dont need it any more | |
| 17:08:55 | stephenfin | To the best of my knowledge, it's a carbon copy of unittest.mock from the latest stable python | |
| 17:09:10 | stephenfin | including all the new features and bugfixes found therein | |
| 17:09:18 | prometheanfire | if the mock-4 releases are bad they should be masked so they don't bug me every day when the constraints bot review fails because nova doesn't work with the new mock (but other projects aparently do) | |
| 17:10:03 | stephenfin | prometheanfire: I'm almost certain we're seeing the exact same issues with unittest.mock on either python3.9 or python3.10 | |
| 17:10:07 | sean-k-mooney | stephenfin: there was deffinlty differnt behavor in the past as code in neutorn would not work in nova | |
| 17:10:32 | stephenfin | and there's an open bug against it but it hasn't gone anywhere | |
| 17:11:02 | stephenfin | prometheanfire: Have you link to a failing constraints bot job? | |
| 17:11:05 | stephenfin | *a link | |
| 17:11:07 | prometheanfire | yep | |
| 17:11:17 | prometheanfire | https://review.opendev.org/776967 | |
| 17:11:25 | stephenfin | ta | |
| 17:12:00 | prometheanfire | was the previous work abandoned? switching to unittest.mock iirc | |
| 17:12:26 | stephenfin | it's not abandoned in Gerrit terms, but nobody is looking at it | |
| 17:12:50 | stephenfin | https://review.opendev.org/c/openstack/nova/+/714676 | |
| 17:12:50 | sean-k-mooney | this is becasue of eventlets and py39 | |
| 17:12:55 | prometheanfire | which is why I pinged :P | |
| 17:12:59 | sean-k-mooney | the websocket proxy is broken on py39 | |
| 17:13:06 | sean-k-mooney | because of dnspython | |
| 17:13:13 | prometheanfire | ya, turtles | |
| 17:13:37 | sean-k-mooney | well actull its brok on 36 too | |
| 17:13:52 | sean-k-mooney | eventlest does not supprot dnspython 2.0 | |
| 17:14:09 | stephenfin | prometheanfire: Yes, look https://review.opendev.org/c/openstack/nova/+/714676/9/nova/tests/unit/console/test_websocketproxy.py | |