15:02:14 #startmeeting Glance 15:02:15 Meeting started Thu Jan 8 15:02:14 2015 UTC and is due to finish in 60 minutes. The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:18 The meeting name has been set to 'glance' 15:02:20 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 15:02:20 o/ 15:02:30 #topic Updates 15:02:47 Happy new years guys 15:02:56 zhiyan: happy new year! 15:02:58 happy new year everyone 15:03:03 (even i do lunar one) 15:03:06 #info Mini summit head count - expected ~15 or less 15:03:22 Oh yes , happy new year :) 15:03:45 :) 15:03:49 Please enter details soon for the same 15:03:55 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 15:04:04 oops 15:04:07 #link https://etherpad.openstack.org/p/kilo-glance-mid-cycle-meetup 15:04:39 #link http://osdir.com/ml/openstack-dev/2015-01/msg00098.html 15:05:31 Whatever I had to say about it is in Participation and Sessions section of the meeting agenda etherpad 15:05:31 * sigmavirus24 is disappointed that he won't be making the mid-cycle 15:05:48 sigmavirus24: that makes it 2 of us 15:06:00 Please let me know if anyone has any concerns 15:06:57 Given the limited amount of expected participation, it feels okay for us to keep a couple of hours of open discussion on both days 15:07:28 Most likely the schedule can be set mid-late next week. 15:07:34 nikhil_k: do we need to try remote way? i probably can help test it 15:07:39 Remote participation is still being figured out 15:07:52 nikhil_k: +2 for having the schedule ready next week 15:08:02 zhiyan: yeah, the event manager is trying to figure it out 15:08:22 nikhil_k: happy to know it 15:08:24 flaper87: about your topic, it might take a just bit more time to co-ordinate with Nova 15:08:40 Hope to keep it on Tuesdays tentatively 15:08:49 s/Tuesdays/Tuesday/ 15:09:10 nikhil_k: +2 15:09:10 Does anyone have anything more to add? 15:09:23 I won't be able to attend so anything I can do from here, I'll do. 15:09:50 flaper87: ok, sounds good. Thanks! 15:10:16 next up 15:10:30 #topic Stuff to be corrected. 15:11:01 I've mentioned to a few folks on our project channel to be more vigilant about the reviews 15:11:34 seems like we've a lot more code being proposed from new contributors to Glance 15:11:54 to add to that we have made some mistakes ourselves 15:12:34 Commit messages, improper splitting of the Merge Props, security bugs - these are some of the categories which have been very error prone lately 15:13:00 I believe this needs to be corrected and 15:13:18 the first responsibility is mine, so here are some of the action items from my end 15:13:42 1. scrutinize the reviews, provide feedback to the reviewers 15:14:08 2. get a Glance specific review guideline list 15:14:10 besides 15:14:19 #link http://docs.openstack.org/infra/manual/developers.html#peer-review 15:14:38 what is improper splitting of the merge props? 15:15:12 3. scrutinize bug descriptions and tally them with the reviews and sync with core and non-cores about the same (enhanced best practices) 15:15:15 FWIW, I think the best way to help people improve their reviews is by commenting on the same patch and pointing out things that are missing in the patch 15:15:37 for example, if I see a commit message that is not proper, I'd ask the author to provide a better error message 15:15:44 flaper87: That is an ideal case, it has not been happening lately. 15:16:06 Moreover, cores are proposing and +2/Aing such changes 15:16:21 which is what calls for added measure 15:16:42 right, I'm pretty sure I've done it too. 15:16:50 On other projects there has typically been resistance to asking people to improve commit messages beyond adding DocImpact (or some other flag), I wasn't sure if it was acceptable here too 15:16:57 I am compiling a list of such errors and common gotchas 15:17:14 nikhil_k: perhaps examples would be helpful to some people as well, if you're okay with that 15:17:26 Will be sharing it with a few active devs first and then have it circulated widely 15:17:32 +1 15:17:34 It's also very easy to amend the commit message via gerrit for trivial changes 15:17:36 sigmavirus24: TravT_ ^ 15:17:41 kragniz: agreed 15:17:52 I think asking for better commit message is fine and must be done 15:17:55 kragniz: glad that you brought it up 15:18:07 If it's easy, why are reviewers not using it 15:18:18 it's not a matter of fixing typos but providing a message good enough to help people understand what's happening in the patch 15:18:33 The problem does not seem to be with ease, rather with missed review guidelines 15:18:34 nikhil_k: if you amend the commit message you'll be set as committer 15:18:45 nikhil_k: agreed 15:19:11 flaper87: that too, however in a must do situation reviewers can do it 15:19:29 yup 15:19:39 Also, this devaluates the importance of +1s 15:20:28 Right now, I'm not so confident to even +2/A a patch which has as many as 2-3 +1s 15:21:09 Ideally, the to-be cores should study the patch and bring out fallacies in fewer PS 15:21:23 that way it gives core reviewers to move the queue quicker 15:21:33 As bad as it sounds, I don't normally trust +1's as I trust -1's 15:21:56 flaper87: agreed, however 15:21:58 "don't normally" to be read as "almost never" 15:22:14 many times there are arguments that a patch has 5 +1s and does not have a +2 15:22:34 think, the reasons are stated above 15:23:21 The review guidelines doc was being prepared however, it got delayed with k1 in the middle 15:23:30 yup, if the patch is trivial, I'd probably feel confident to +2/A, otherwise I'd just +2 15:23:31 Best to catch up with it son 15:23:34 soon* 15:23:41 nikhil_k: agreed 15:26:15 ping ? 15:26:21 move on? 15:26:35 Are there any questions on this topic and on the specs details mentioned in the etherpad? 15:27:11 ok, next topic 15:27:14 nikhil_k: all sounds good to be worked on in the future 15:27:14 #topic Shout outs 15:28:01 #info jokke_ did some excellent work on stability, especially when the gate was broken 15:28:51 #info kragniz has been extremely vigilant on various aspects and had pointed out that we missed an important commit in k1 15:28:59 * flaper87 now knows why kragniz wanted to move on 15:29:06 \o/ thanks! 15:29:06 jokes apart: 15:29:10 flaper87: haha 15:29:13 kragniz: jokke_ great work 15:29:19 thanks for all the efforst there 15:29:26 :) 15:29:32 efforts* 15:29:40 jokke_ kragniz and sigmavirus24 : Have been excellent with bug triage, releases, etc. 15:29:44 thank you joke kragniz 15:30:21 Kudos to these folks for taking up the often neglected yet important part of the project! 15:30:31 but it's fun stuff ;) 15:30:32 great work! 15:30:56 Anyone else that you all noticed? 15:31:32 nikhil_k: and flaper87 ? :) 15:31:42 cpallares has been catching some excellent things on review too 15:31:49 zhiyan: :) 15:32:02 sigmavirus24: right, cpallares has been doing an awesome work 15:32:12 (Shame she isn't here at the moment) 15:32:44 #info cpallares has been catching some excellent things on review too (and flaper87 agrees ;)) 15:32:53 woot! 15:33:01 ivasilevskaya, too 15:33:17 Awesome 15:33:45 ok, ok, ok ok, Iiiiiiiiiiiiiiiiiiii geeeet it, glance's community is super amazing! 15:33:45 #info cpallares and ivasilevskaya - thanks for your efforts and good work! 15:33:55 congrats everyone for your hard work 15:33:57 :)) 15:33:59 lol, flaper87 15:34:08 :P 15:34:09 but yeah, something like that 15:34:25 #topic Reviews/Bugs/Releases 15:34:31 flaper87: better than rust? =P 15:35:18 Follow up from previous discussion, please make a note to tag, link and mark the bug/review appropriately for expecting it to be in a release 15:35:37 sigmavirus24: no 15:35:42 erm, I mean, yes 15:35:44 :P 15:35:45 lol 15:35:50 I believe, our current way of handling releases has been working well 15:36:08 nikhil_k: this is marking it in launchpad, right? 15:36:19 To avoid missing important commits in major releases like k2 - please be extra careful. 15:36:19 nikhil_k: one clarification: should we mark a bug as k-2 if we think it *should* be in there or if we think it will be able to make it in there? (or both?) 15:36:22 kragniz: yes 15:36:33 cool 15:36:50 sigmavirus24: the bug supervisor can mark it k2 as long as we are confident 15:37:07 would like to avoid clutter in the release page 15:37:19 Understood. :) 15:37:21 release management wont be much happy 15:37:24 Thanks for clarifying 15:37:42 #topic Stable branch for glance_store 15:38:11 Any takers? 15:38:19 o/ 15:38:43 it's funny... the most mentally unstable dude in this group takes care of stable branches 15:38:51 that'd be me :P 15:38:56 lol 15:39:15 I'm already in the global stable team 15:39:16 #info talking about telcowg in next summit, that will be too late for getting featutres into l1 as now its k2/k3 at most for now 15:39:30 if some glance-core wants to take care of our glance/glance_Store stable branches 15:39:32 it'd be great 15:39:43 flaper87: maybe you need to be a little unhinged to take them on :P 15:39:59 flaper87: o/ 15:40:19 flaper87: we are supposed to have a stable team for Glance 15:40:20 Rather join weekly telcowg at Openstack and get our OPNFV requirements early in k2..cycles 15:40:29 rprakash_: wrong channel? 15:40:33 lemme rephrase that, it'd be good to have one more guy besides me looking after stable branches 15:40:38 sorry folks 15:40:55 nikhil_k: right, I knew I had to rephrase that phrase :P 15:41:12 flaper87: The overall Glance stable team would be a good choice, imho 15:41:23 * flaper87 agrees 15:41:32 I'm happy to be part of it 15:41:35 That can include repr from each of the store drivers 15:42:17 * nikhil_k suggests that approach to be able to tackle security/stability isssues faster 15:42:51 * nikhil_k hands are so cold to type correctly :P 15:43:20 nikhil_k: you're in VA. It's -25F with the windchill where I am 15:43:39 (Approx -32C) 15:43:48 dearness 15:44:05 sigmavirus24: yum 15:44:06 * flaper87 is living the weirdest winter ever... it's like 5C outside 15:44:26 my place approx -20c 15:44:34 zhiyan: ^5 15:44:40 o.0 15:44:52 outside i mean 15:45:01 ok, next one? 15:45:03 9C here! 15:45:07 zhiyan: LOL, yeah, I figured :P 15:45:09 lol zhiyan 15:45:12 7C here 15:45:16 it's mine 15:45:16 ok, next 15:45:19 Take 77 here 15:45:20 who else? who else? 15:45:20 (outside) 15:45:31 :) 15:45:31 #topic Cancellable store.add operation 15:45:37 aaaaaaaah :( 15:45:59 not #topic weather? :P 15:45:59 zhiyan: ? 15:46:23 yes. cool. when i fix the bug, i think we'd better do a enhancment for glance. 15:47:01 currently, glance allow use deletes image which under uploading stage - 'saving' status. 15:47:59 Hmm, that would be tricky to do 15:48:06 so use could use image-delete to cancel the uploading, or just remove a 'bad' image (think about nova capturing image get wrong/failure) 15:48:25 currently we already support it 15:48:51 but a issue exist in glance, if you interest pls check/review https://review.openstack.org/#/c/144464/ 15:49:29 the point it that, even we support that, it has some delay 15:50:44 zhiyan: the tricky part is for the uploader thread to check the status in intervals during the upload 15:50:53 it can be bad on the DB 15:51:11 even image-delete image metatdata get delete from db and the request return to end user immediately, but actually the previrus uploading is still executing. 15:52:13 zhiyan: The situation does not look good however, the alternatives are not great either. Do you have a proposal in mind? 15:52:28 due to currently glance can only get stored image location when store.add() return, so concurrent glance-delete couldn't remove any on-going chunks 15:52:52 yes 15:53:05 so i think we need to way to break store.add() 15:53:37 Is there a spec for this? 15:53:52 that means when an image get delete, we need ask store to cancel on-going uploading operation. then the uploading 'thread' will notice it (by an exception glance_store raised out) 15:53:58 * nikhil_k likes where sigmavirus24 is going 15:54:03 sigmavirus24: not yet, in my mind now. 15:54:16 nikhil_k: that's not a big deal, will/i'd like prepare 15:54:32 sg 15:55:01 nikhil_k: actually i think this could be a part of store-capabilities (as a follow-up new cap) 15:55:26 if store support this cap, then we can cancel the on-going upload safely, then finally, that means 15:55:50 end user could 'cancel' a uploading image quickly. 15:55:50 and the quota will never exceeded 15:56:08 might be worth an investigation 15:56:20 * nikhil_k likes the spec idea 15:56:29 i mentioned some details of my thoughts in the last sentence of my comment at https://review.openstack.org/#/c/144464/ as well. 15:56:38 zhiyan: can we give some time for open discussion? 15:56:49 sure 15:57:01 zhiyan: Thanks for the detailed analysis. Much appreciated! 15:57:07 #topic Open Discussion 15:57:11 hmm ok. 15:57:57 just a heads up: https://review.openstack.org/#/c/144875/ 15:58:01 that baby is out there 15:58:20 nikhil_k: so i'd like to add that stuff as a topic for mid-cycle meeting, sounds good? 15:58:21 flaper87: woah! nice ;) 15:58:22 Figting with gate failures right now but I think I'll get it done soon 15:58:42 zhiyan: yeah, def 15:58:54 zhiyan: will you be attending? 15:59:02 nikhil_k: remote 15:59:09 flaper87: it's looking nice! 15:59:18 (always remote, Hmm) 15:59:33 how many people will actually be in person? 16:00:03 10-15 prolly 16:00:48 Thanks everyone! 16:00:53 #endmeeting