14:00:28 #startmeeting glance 14:00:29 Meeting started Thu Apr 8 14:00:28 2021 UTC and is due to finish in 60 minutes. The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:33 The meeting name has been set to 'glance' 14:00:35 #topic roll call 14:00:44 o/ 14:00:47 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:00:49 o/ 14:01:01 lets wait couple of minutes for others to join 14:01:25 hoping for at least rosmaita so I can bug him about reviews :) 14:01:45 he will be around :D 14:01:45 i should have some time today 14:01:49 o/ 14:01:51 o/ 14:02:00 cool, lets start 14:02:09 #topic Updates 14:02:21 #link https://etherpad.opendev.org/p/xena-ptg-glance-planning 14:02:33 So most of the topics are final 14:03:10 RBAC related discussion will be on Wednesday, and cross-project discussion with cinder will be either on Thursday or Friday 14:03:51 can we make it thursday? 14:04:04 We could have couple of empty slots, so if you have anything in mind please add it to planning etherpad 14:04:21 rosmaita, yep, Thursday then 14:04:57 I will update the etherpad accordingly 14:05:28 any questions? 14:05:47 cool, moving ahead 14:05:50 #topic release/periodic jobs update 14:06:06 thanks! 14:06:22 We are good with release, I will be tagging stable releases next week 14:06:50 will we do an rc2 for the bug fix that merged today? 14:06:57 or just backport after the release? 14:07:29 I think backport should be better one 14:07:36 ack 14:08:28 Periodic job, one failure due to mirroring 14:08:54 else it is green 14:09:05 moving ahead 14:09:15 #topic glance/glance-store job 14:09:37 So recently we added one job in glance-store to run glance functional tests 14:10:09 as it is a voting job, it is failing on glance-store change 14:10:44 and we can not add depends on as it requires depends on both the patches (glance-store as well as glance) which is not possible due to circular dependency issue 14:10:45 that was the point of it, right? ;) 14:10:53 yeah, so what this shows, is that you're breaking the library 14:10:54 glance_store: https://review.opendev.org/c/openstack/glance_store/+/782200 14:11:17 the voting of it is doing exactly what we want, IMHO, which is to make sure a glance_store change does not break glance 14:11:17 yeah, so workaround is to skip those tests, right? 14:11:39 I'll have to look at the failure and cause, but I'd say no 14:11:54 glance: https://review.opendev.org/c/openstack/glance/+/784748 14:12:06 yep, I've got them up and will look after my meetings this morning 14:12:36 ack 14:12:52 thank you 14:13:17 moving ahead 14:13:32 #topic Possible improvement for image upload speed 14:13:48 #link https://bugs.launchpad.net/glance/+bug/1921953 14:13:50 Launchpad bug 1921953 in Glance "The upload of image is slow" [Undecided,New] 14:14:16 I think whoever added this topic didn't mentioned that this improvement is specific to swift store 14:14:53 and neither he/she is around at the moment 14:14:54 and, 14:15:03 there's no link to the proposed patch that I can see, right? 14:15:17 Nope; 14:15:19 Hi! Right 14:15:25 i'll prepare patch 14:15:49 GlaciErrDev, I think this should go as improvement rather than bug 14:15:56 agree 14:16:00 Sure 14:16:04 Thanks 14:16:10 so if possible please submit a design spec 14:16:20 are you aware about glance-specs ? 14:16:26 no 14:16:41 #link https://github.com/openstack/glance-specs 14:16:50 thank you 14:17:07 ok, here you can find specific template and also refer other available specifications 14:17:07 GlaciErrDev: so what changes are you actually proposing? Is it just swift store driver change to call some other function in swiftclient or something more complex? 14:17:28 jokke, I guess former one 14:18:20 GlaciErrDev, and if you still have some doubts we can sync after the meeting and I can explain you more about the specs 14:18:21 I've just used ThreadPoolExecutor to execute in parallel `put_object` from swift 14:18:57 GlaciErrDev: if you're talking about a new thread per block, that could cause glance memory usage to skyrocket during upload, which is why we should have a spec 14:19:12 ++ 14:19:41 actually this call `manager.get_connection().put_object(...)` 14:19:52 I see 14:20:11 Yeah, I'd be very cautious about that. While one might find good performance increase in single operation we need to make sure we stay stable and perform well when there is 10s of them inflight 14:21:01 yup 14:21:17 I've tested with one upload operation a time... 14:21:53 GlaciErrDev, so first submit a spec, you can also add your results in the specs 14:22:20 abhishekk ok, will do it 14:22:31 GlaciErrDev: like abhishekk said, put your findings and what you did in a spec (lite should be sufficient as there is no API change involved) and lets see if it makes sense 14:22:33 If required I will walk you through it 14:23:07 abhishekk probably it will help me a lot 14:23:08 cool, GlaciErrDev thank you, 14:23:14 Thanks! 14:23:26 we will sync after the meeting 14:23:29 moving ahead 14:23:49 #topic XS reviews 14:24:04 this must be Steap 14:24:32 yeah 14:24:52 stage is yours 14:25:03 1 got an XS review and I think abhishekk marked a bunch of bugs ready to close 14:25:10 https://review.opendev.org/c/openstack/python-glanceclient/+/784465 is an old Py3 issue we missed 14:25:21 it does not seem to be triggered, but we might want to be safe 14:26:30 Steap, I have added comments on the bugs and haven't got any replies on them yet, so those one with no replies we can close them 14:26:43 yeah there is a list at https://etherpad.opendev.org/p/glance-bug-tracker 14:26:49 you left them 1 week, right? 14:27:25 yeah 14:27:47 I haven't said that on bug to revert within a week or else we will close it 14:27:55 hehe I give them 1 month, you're not as nice as me 14:28:01 :D 14:29:10 so, -10 bugs \o/ 14:29:40 yep, and there are some stable branch related bugs as well at the bottom 14:30:39 So I guess that's it from this topic, please have a look at review pointed by Steap 14:30:46 Moving to Open discussion 14:30:54 #topic Open discussion 14:31:23 Open question for rosmaita 14:31:34 #link https://review.opendev.org/c/openstack/glance/+/783668 14:31:35 ? 14:31:36 Steap: abhishekk: about the socketIO ... where is that coming from? I can't seem to find it in the stdlib socket docs 14:31:48 just a poke for him to circle back to that so I can revise :) 14:32:17 hm 14:32:19 weird 14:32:23 ok, consider me poked 14:32:50 jokke: oh it's in the code for sure, but seems undocumented 14:33:42 Steap: so it's not coming from the python-socketio package we do not depend on? 14:33:48 jokke, I have just verified by dir(socket) 14:34:36 jokke: no, it's socket.SocketIO 14:35:21 #link https://review.opendev.org/c/openstack/glance/+/783893 14:35:37 rosmaita, Steap I have fixed your comments/suggestions on above patch 14:36:00 Thanks, I'll recheck 14:36:11 cool 14:36:12 abhishekk: 3.7.7 does not have it 14:36:21 I just did dir(socket) there 14:36:43 oh, I have 3.6.9 14:37:12 really? 14:37:45 I think e need test going with that patch which actually executes the codepath 14:38:13 yeah I'm not sure when this code is triggered 14:38:21 dansmith: commented on your patch 14:38:38 sorry, my bad there is indeed SocketIO in 3.7.7 14:38:39 python3 -c "import socket; print('SocketIO' in dir(socket))" 14:38:39 True 14:38:46 yup 14:38:51 rosmaita: thanks 14:41:09 Steap: abhishekk: so that established, as there is no documentation of that do we know it actually works same way or at all? Back to the point, if we did not catch socket._fileobject missing, we likely should have a test touching thta codepath showing that the SocketIO actually works as intended 14:42:18 Steap, could you please add the test ? 14:42:38 Honestly, I'm not sure what this code does. My reasoning here is that _fileobject is 100% sure to crash on us, while SocketIO seems to be the usual fix in projects that went from py2 to py3 :) 14:43:19 neither do I, I will try to work on the test then 14:43:45 Maybe the code is never actually used and we can just remove it 14:43:48 * Steap likes to dream 14:43:55 I'll put that into my list of things to look at too to figure out what we actually do there. Thanks! 14:44:06 jokke, cool, thank you 14:44:16 anything else? 14:44:31 abhishekk: whoami-rajat: btw about that glance_store patch ... I missed my opportunity at the time 14:45:05 anything to mention? 14:45:14 abhishekk: one more thing 14:45:18 ah is it already discussed? sorry i missed it 14:45:41 I think rosmaita's type is fixed here: https://review.opendev.org/c/openstack/glance/+/783893 14:45:42 and hoping anyone else that had comments has done so, so can we merge? 14:45:45 Is there no way to not break glance on that? (I'm not sure the test change apart from lots of extra mocking looked like there was logic change) if that breaks the store python API that basically would need major version bump on glance_store 14:46:09 jokke: it looks to me like it's just breaking the fact that glance is mocking the internals of glance_store 14:46:30 jokke: which isn't technically a violation, and more just a problem of glance_store not exporting a stable Fixture for tests I think 14:46:46 jokke: I think putting the glance test fix in front of the glance_store patch will probably make it work 14:47:08 but I need to test.. it's just that glance is providing the client mock that glance_store ends up using I think 14:47:16 but I just briefly looked over it here in the meetnig 14:47:19 dansmith, regarding https://review.opendev.org/c/openstack/glance/+/783893 14:47:31 just to give my thoughts, my patch changes mostly the whole functional flow of current glance cinder to a new one so all old methods used are invalid hence the test fails 14:47:39 if there are no more objections by tomorrow then we can move ahead with this 14:47:46 dansmith: yeah same, you might be right it was just los of changes in the tests but indeed looks like loads of mocking 14:48:00 jokke: yeah I think it's just the mocking, unfortunately 14:48:06 abhishekk: okay 14:48:48 I think during X we should also try to put efforts in our tests to remove mocking as much as possible 14:49:30 abhishekk: you mean across the seam of glance/glance_store right? 14:49:38 in that case I'd suggest to put a patch to skip that test in glance functional with heavy todo note, merge the _store path, release the store and drop the skip. Rather than drop the whole test job to get it merged 14:49:44 I would like if we made that job non-voting and i can propose a WIP fix to glance if it breaks and we can merge that patch when glance store releases but that's just my thoughts to make my work easier 14:50:16 jokke: I really think we can make the glance tests account for both cases and then merge the glance_store patch after that 14:50:48 i.e without skips or disabling the test 14:50:56 dansmith: that would be great if you want to put your testing/mocking wizardry into action. I wouldn't even dare to try ;P 14:51:18 I don't think it'll be that bad, but yes I'll be glad to try before we do something more drastic 14:51:30 that will be great, 14:52:14 Hihi ... what comes to testing and specially mocking axe and sledgehammer tends to be my finetuning tools :P 14:52:21 Last option would be report a bug in LP, skip the tests, release glance-store and then fix the bug 14:54:04 abhishekk: yeah, well anyways if Dan can figure out way not needing to do that, even better. But I'd just rather not disable the whole job cause it works as intended :P 14:54:27 ack 14:54:52 I got it 14:54:54 will push up in a few 14:54:58 <3 14:55:02 cool 14:55:18 anything else ? 14:55:31 * jokke needs to start designing "mockwizzard" pointy hat 14:55:46 so we can send one to dansmith 14:55:59 nothing else from me 14:56:12 ok, time to wrap up 14:56:20 thank you all 14:56:38 #endmeeting