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