14:01:38 #startmeeting glance 14:01:39 Meeting started Thu Aug 6 14:01:38 2020 UTC and is due to finish in 60 minutes. The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:42 The meeting name has been set to 'glance' 14:01:45 #topic roll call 14:01:48 o/ 14:01:50 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:01:52 o/ 14:01:53 o/ 14:01:59 o/ 14:02:13 o/ 14:02:21 lets wait couple of mins for rosmaita 14:03:20 o/ 14:03:30 cool, lets start 14:03:31 (i am only partially here) 14:03:34 #topic Updates 14:03:36 o/ 14:03:46 rosmaita: that is fine, we only need your brain! 14:04:11 Welcome Dan to the cores group 14:04:13 there is not enough of that to go around 14:04:22 congratulations, Dan! 14:04:31 woo 14:04:32 gg, Dan! 14:04:43 Welcome and congratulations Dan!! 14:04:51 Steap, means cyril? 14:05:04 oh 14:05:17 "gg" is "good game", but it may not be completely mainstream yet 14:05:20 * Steap is ahead of his time 14:05:23 Steap: you need to call yourself 'Bruce', it will be less confusing 14:05:34 Sorry :D 14:06:04 Dan is helping us a lot and hopefully he will stays with us little longer :P 14:06:11 Moving ahead 14:06:21 #topic release/periodic jobs update 14:06:34 stable/train and stable/ussuri release for glance 14:07:08 Still there are couple of patches under review or in the gate, So I will suggest we should release both on Monday 14:07:13 any objections? 14:07:29 jokke ^^ 14:07:48 if we get the ussuri backports in I can push the release patch up to review today 14:08:07 If that happens then its good 14:08:16 otherwise we will release on Monday 14:08:28 client patch is up already and has +2 from smcginnis the glance side needs those backports still 14:08:51 yeah 14:08:55 Final release for non clients libraries - 3 weeks from now 14:09:17 that means we need to get cinder multiple stores specs in by tomorrow EOD 14:09:37 I am ready with the PoC just need to work on tests and polishing little bit 14:10:00 rosmaita, smcginnis kindly have a look at cinder multiple stores specs 14:10:15 ack 14:10:22 V3 milestone 4 weeks from now 14:10:30 just month remaining 14:11:02 we need to get image encryption, sparse image handling, virtual size calculation and multiple cinder stores work done before this 14:11:17 I guess Luzi is here 14:11:37 Could you please share updates about image encryption work? 14:11:46 mhen, as well 14:12:44 ok, we will get back to this in Open discussion 14:12:48 we are currently waiting on the Barbican Secret Consumer API 14:13:02 they had some issues with the gate-jobs 14:13:07 what is ETA for that 14:13:21 are we positive to get this done in Victoria? 14:13:54 i am not sure 14:14:32 Ok 14:14:43 thank you for the update 14:15:06 Keep us posted about the progress if possible 14:15:09 mostly depends on Barbican and how quick their new API is available to us and how much time we have left for the necessary adjustments to incorporate the new API then 14:15:49 mhen, I am asking because if we are certain then we can file for FFE if required 14:16:40 Lets revisit the status in next week and then we will decide whether to move it to next cycle or not 14:16:55 Moving ahead 14:17:07 #topic Specs status 14:17:40 we still have 5 specs open for reviews 14:17:45 Make cinder driver compatible with multiple stores - https://review.opendev.org/695152 - Need reviewes 14:17:45 Introspect import plugin to calculate virtual size of image - https://review.opendev.org/741121 - Need reviews 14:17:46 Optimize Ceph store network usage - https://review.opendev.org/#/c/740980/ - Need reviews 14:17:46 Update proposal for duplication image download - https://review.opendev.org/734683 - Need reviews 14:17:47 Cache API - https://review.opendev.org/#/c/665258/ - Need reviews 14:18:07 Out of which 1st are almost ready to go 14:18:15 Code is ready for both of them 14:18:26 * Steap really needs to work on the cache api spec a bit more 14:18:28 SO kindly review them on top priority 14:18:46 For https://review.opendev.org/#/c/740980/, I still think example will help to validate the optimization 14:19:03 abhishekk: I will +2 the virtual size one after this when I re-read it, but should be fine I think 14:19:14 jokke I can try to find it if you want (but I have also lot of work sparse upload side :p ) 14:19:15 dansmith, ack 14:19:36 alistarle, focus on sparse upload first 14:19:48 :D 14:20:09 Moving to next topic 14:20:16 #topic Work moving to W cycle 14:20:29 alistarle: yeah, lets try to get your sparse stuff in, that rest of the ceph stuff has been kind of waiting to layer on top of the work you guys already did 14:21:05 Due to lack of time I am suggesting to move below items to next cycle 14:21:14 Code cleanup (ToDo items from code) - https://ethercalc.openstack.org/kq4gwn9gqzck 14:21:29 restrict Duplicate downloads 14:21:35 Cache API 14:21:41 Cluster awareness for glance 14:21:48 Remove single store configuration 14:22:00 * Steap is OK with moving Cache API 14:22:25 I am still putting efforts on removing single store configuration but I am doubtful to complete it within 3 weeks 14:22:33 I was just gonna ask if Steap thinks the cache api is doable within the timeframe we have 14:22:55 For Cache API I have PoC ready 14:23:27 I'm around for about two and half weeks still. Then i will disappear into the forest for a week :P 14:23:27 https://review.opendev.org/#/c/672876/ 14:24:01 I hope everyone agrees on the work I selected to Move to next cycle 14:24:45 * abhishekk good for you jokke :D 14:25:39 Cool, moving ahead to Open discussion 14:25:54 #topic Open discussion 14:26:18 Between Luzi and mhen thank you for joining in and sharing the updates 14:26:30 jokke: yeah I still need to disappear as well, so... :) 14:27:06 I have one topic for discussion 14:27:19 I have seen code-coverage job for most of the core projects 14:27:31 like nova, cinder, neutron etc 14:27:46 any idea what is usefulness of it? 14:27:56 rosmaita, dansmith ^^ 14:28:17 We used to have one I think we got rid of it as no-one ever paid any attention to it 14:28:28 in nova, it's not much use, IMHO 14:29:07 in other projects I've used a coverage tracking tool to make sure that stuff that is added gets tested, 14:29:10 well, it's useful to see what the coverage is on new patches 14:29:10 as far as I think the purpose should be look at the results and see whether code added is covered or not 14:29:24 but with such a large and indirectly-connected project, it can be hard 14:29:33 do we really have time to check this? 14:29:37 yeah, it was one of those things the Rackspace/Intel guys were active on and when that project got carpet pulled under it no-one just paid any attention to it so IIRC we removed the job to release that bit of resources back to infra pool 14:30:15 glance seems to be missing a lot more coverage than nova does though, so it may be useful here if the data is presented in a useful format 14:30:29 but it requires diligence by the cores to check it and force people to write tests 14:30:37 ++ 14:30:41 so if that's not going to happen, then it's just a waste of infra resources 14:30:58 i think tox gives that info for you, so you can just run it locally to see what's in the report 14:31:06 it's also something you can do by downloading a patch and determining it yourself 14:31:19 which nobody does 14:31:21 tox doesn't unless you run pycoverage or something, that I know of, 14:31:28 but yes, it's doable locally 14:31:52 I guess next cycle we should add one goal to increase code coverage of glance 14:32:05 we have tox env called cover for it 14:32:22 I think we have tox -e coverage or cover in glance tox.ini 14:32:25 jokke: yeah, that's not tox, that's just us configuring tox to run a coverage tool 14:32:48 abhishekk: just to be clear, adding a job does not increase coverage... only humans increase coverage :) 14:32:50 dansmith: sure yeah, but I mean we do have tooling via tox to do it locally was what I meant 14:33:02 dansmith: ++ 14:33:03 dansmith, yeah I know that :D 14:33:33 abhishekk: just saying, it's easy to say "we'll add the job" and start consuming resources, but then never do anything about it, so... need some policies and procedures... and policing :) 14:33:53 dansmith: and that was why we removed the job last time :D 14:34:08 dansmith, yes, thats why I asked what are the benefits of having it 14:34:17 yep, but if the policing will be there, I'm all for it, because.. there's a lot of uncovered stuff 14:34:25 can't the job be a voting one then ? 14:34:34 we can have a gate job only for new code coverage 14:34:41 alistarle: not really, 14:35:13 because there are always lines you can't cover that don't matter much, and making the job refuse to merge a patch because you didn't roll over some docstring line is a real problem 14:35:25 we need something like the job should fail if that patch has less than 50% code coverage 14:35:25 in cinder, we decided at the ptg to do it as a non-voting job and revisit at the next ptg to see if anyone is using it 14:35:26 the tool generally just *reports* coverage, and you have to decide whether you're okay with the report 14:36:10 we can also restrict the coverage on some part of the code 14:36:11 yeah, that's really time consuming though it is good practice 14:36:39 also it was driving behaviour where people wrote pretty much literally tests like assetEqual(configoption, configdefault) just to get the coverage number up. We need meaningful tests, not just more tests 14:36:59 ++ 14:37:47 Yep, and btw I think we are more lacking of corner cases integration test than unit test 14:39:03 we could do a lot better by increasing the requirements the reviewers place on new patches and that's "free" in that it only demands the core time part of the coverage equation 14:39:18 and then worry about tooling when we're starting to wonder how close to 100% we are :) 14:39:24 ++ 14:39:39 :D 14:41:37 Ok, any other topic for discussion?? 14:41:54 Concerning sparse upload, we finally admit it will be far easier to test all the case from gerrit than on premise :p So we submit this first version : https://review.opendev.org/#/c/744282/ 14:42:17 rosmaita: smcginnis: the two ussuri patches we're looking to include in the stable release are https://review.opendev.org/744997 and https://review.opendev.org/745100 if you have time 14:42:41 We still have issue with covering all checksum validation case, but we are working really faster in that condition than in our own environment 14:43:04 alistarle, let us know if you need anything 14:43:26 I hope next week it will be fully fonctionnal 14:43:47 cool 14:43:55 and I also submit a talk to the virtual summit about our multi AZ setup, will talk about glance multi store for sure 14:44:12 \o/ 14:44:38 nice 14:45:01 But I don't know if it will be selected ;) 14:45:12 :d 14:45:27 B+ve 14:46:31 Ok that's it for me today 14:47:17 lets wrap up unless anyone wants to discuss or share any updates 14:48:40 I have nothing else for now 14:48:50 cool, thank you all 14:48:55 have a nice time ahead 14:49:10 thanks all 14:49:47 #endmeeting