| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-03 | |||
| 16:14:41 | melwitt | we're on our second recheck trying to merge one of the gate unblocking patch on stable/ussuri https://review.opendev.org/c/openstack/nova/+/838033 :\ | |
| 16:15:04 | melwitt | for bug 1901739 | |
| 16:15:33 | gibi | and the original fix was to switch to zuul v3 :/ | |
| 16:15:42 | elodilles | yepp, it seems ussuri is not that healthy as it should be :S | |
| 16:16:03 | elodilles | gibi: and as far as i remember we did not need that for ussuri | |
| 16:16:13 | elodilles | so this is something "new" | |
| 16:17:30 | gibi | hm we do merged the ussuri backport https://review.opendev.org/c/openstack/nova/+/795432 | |
| 16:18:08 | gibi | that should have fixed 1901739 but appreantly it did not | |
| 16:19:22 | elodilles | oh. hmmm, yes, we did not backport it to *train*... | |
| 16:19:37 | gibi | that is all I can add to this right now :/ | |
| 16:19:37 | elodilles | then this is definitely something "new" | |
| 16:21:15 | bauzas | could we discuss about the stable branch gate issues during the stable topic, maybe ? | |
| 16:21:32 | elodilles | ++ :) | |
| 16:21:59 | elodilles | (i planned to note this there) | |
| 16:22:32 | bauzas | ok, then next topic | |
| 16:22:37 | elodilles | (otherwise i don't have much to add for now) | |
| 16:22:41 | bauzas | #topic Release Planning | |
| 16:22:47 | bauzas | #link https://releases.openstack.org/zed/schedule.html | |
| 16:22:51 | bauzas | #info Zed-1 is due in 2 weeks | |
| 16:22:55 | bauzas | #info Spec review day planned on May 10th | |
| 16:22:59 | bauzas | ... which is next week | |
| 16:23:09 | bauzas | I've seen some new specs | |
| 16:23:14 | melwitt | sorry, I thought stable gate status was part of gate status | |
| 16:23:20 | bauzas | I'll try to review some of them tomorrow | |
| 16:23:28 | bauzas | melwitt: no worries at all | |
| 16:23:44 | bauzas | but I'd prefer to do this after all the other topics | |
| 16:23:57 | bauzas | so we'll have all the left time for it :) | |
| 16:24:28 | bauzas | anything to say about release planning ? | |
| 16:24:44 | bauzas | keep in mind to upload/update your last specs before next tuesday :) | |
| 16:26:03 | bauzas | looks not | |
| 16:26:21 | bauzas | #topic Review priorities | |
| 16:26:31 | bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1 | |
| 16:26:58 | bauzas | nothing to tell here | |
| 16:30:59 | bauzas | ok, moving on then | |
| 16:31:12 | bauzas | #topic Stable Branches | |
| 16:31:19 | bauzas | elodilles: you can continue the discussion here :) | |
| 16:31:31 | elodilles | well, let's start with the basics :) | |
| 16:31:35 | elodilles | #info ussuri and older branches are blocked until 'l-c drop' patches merge - https://review.opendev.org/q/I514f6b337ffefef90a0ce9ab0b4afd083caa277e | |
| 16:31:59 | elodilles | and as we said something else problematic is there on ussuri it seems :( | |
| 16:32:06 | elodilles | #info other branches should be OK | |
| 16:32:38 | elodilles | EOM | |
| 16:32:54 | elodilles | I don't have other info for the ussuri failures for now :( | |
| 16:35:37 | bauzas | cool | |
| 16:35:42 | bauzas | melwitt: wanting to add something ? | |
| 16:36:01 | melwitt | nothing additional, thanks | |
| 16:36:04 | bauzas | cool | |
| 16:36:13 | bauzas | then we're done with this topic | |
| 16:36:26 | bauzas | #topic Open discussion | |
| 16:36:41 | bauzas | ... and we have nothing about this in the wiki | |
| 16:36:53 | bauzas | soooo, any item to raise before we end the meeting ? | |
| 16:37:13 | gibi | <crickets? | |
| 16:37:15 | gibi | > | |
| 16:38:05 | bauzas | okidoki | |
| 16:38:11 | bauzas | thanks all | |
| 16:38:13 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-03-16.00.log.html | |
| 16:38:13 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-03-16.00.txt | |
| 16:38:13 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-03-16.00.html | |
| 16:38:13 | opendevmeet | Meeting ended Tue May 3 16:38:13 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:38:13 | bauzas | #endmeeting | |
| 16:38:36 | elodilles | thanks o/ | |
| 16:38:50 | gibi | o/ | |
| 16:40:46 | opendevreview | ribaudr proposed openstack/nova-specs master: Allow to use graphviz into specifications https://review.opendev.org/c/openstack/nova-specs/+/840167 | |
| 16:40:47 | opendevreview | ribaudr proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/833669 | |
| 16:45:24 | melwitt | dansmith: I wanted to get your opinion on whether copying exception objects is necessary when referring to them in a new dict or other wrapper https://review.opendev.org/c/openstack/nova/+/840260/2/nova/context.py if you could spare a moment. no rush | |
| 16:47:28 | dansmith | hmm, yeah I thought there was something about it being semi-global in nature, but that might be a py2 thing | |
| 16:49:39 | dansmith | ah your comment is interesting though.. straight up block scoping being more strict in python, but that's not really what is changing here, | |
| 16:49:57 | dansmith | as we're already storing it in the different name, it's the copying part that is in question | |
| 16:50:18 | melwitt | yeah exactly | |
| 16:50:51 | sean-k-mooney | excpetion objects nolonger keep the stack frame alive right via the traceback object | |
| 16:51:13 | sean-k-mooney | so we dont have to worry about it "leaking" memory like it did on python 2 | |
| 16:51:34 | dansmith | https://stackoverflow.com/questions/44681681/what-could-prevent-a-traceback-from-being-garbage-collected | |
| 16:51:41 | dansmith | melwitt: see the last comment in there about py3 | |
| 16:52:07 | dansmith | sean-k-mooney: yeah, that's what I was thinking... the old py2 stuff about things being special there | |
| 16:53:00 | sean-k-mooney | ya so no i think the traceback is generated at the time its raised with a weakref to the stack fram to avoid that issue on py3 | |
| 16:53:00 | melwitt | oh interesting | |
| 16:53:28 | sean-k-mooney | melwitt: we had a case where we were returning raided excations if i rememebr correctly in nova that caused issue in the past | |
| 16:53:46 | sean-k-mooney | possible in relation to the scater gather implementions | |
| 16:53:49 | sean-k-mooney | its been a while | |
| 16:54:13 | melwitt | hrm... yeah that is where the code in question is | |
| 16:54:43 | dansmith | well, it's really anywhere we're persisting the exception outside the handler, | |
| 16:54:51 | melwitt | if we need it I definitely want to put a code comment there explaining why it's needed | |
| 16:54:53 | dansmith | so there might be a thing related to handling in rpc too, but yeah | |
| 16:55:10 | sean-k-mooney | dansmith: righ tbut in that case we wanted to do that to allow the other request ot proceed and deal with it at the end | |
| 16:55:25 | dansmith | in the scatter/gather case yeah | |
| 16:55:28 | sean-k-mooney | we normally dont have a good usecase to persist the object | |
| 16:56:03 | dansmith | right, in the rpc case we do end up raising out of there, you're right | |
| 16:56:20 | dansmith | I hedged with "might" so.. :P | |
| 16:56:42 | sean-k-mooney | :) | |
| 16:57:06 | sean-k-mooney | so back to https://review.opendev.org/c/openstack/nova/+/840260/2/nova/context.py | |
| 16:57:22 | sean-k-mooney | im not sure if a copy actuly breaks the reference ot the stack frame | |
| 16:57:43 | sean-k-mooney | oh its not a copy | |
| 16:57:55 | sean-k-mooney | we are constucting a new instace of the excpetion class | |
| 16:58:03 | sean-k-mooney | wiht the arges for the orgianl excption | |
| 16:58:10 | sean-k-mooney | so ya that would have broken the reference | |
| 16:58:23 | melwitt | yeah I used the word "copy" to mean a new object with the same stuff. sorry if that made it confusing | |
| 16:59:00 | sean-k-mooney | no your fine i just assumed you ment copy.deepcopy just reading the patch now | |
| 16:59:41 | melwitt | sean-k-mooney: so what does that mean, that constructing the new instance is actually bad? I wanted to remove it to make my unit test easier so I was trying to find the inverse, whether it is ok to not construct the new instance | |
| 16:59:56 | sean-k-mooney | i dont have a link to back this up but i belive we dont have to worry about this on python 3 | |
| 17:00:06 | bauzas | looks like a contextmanager question | |
| 17:00:12 | sean-k-mooney | no constucting a new instance is fine | |