14:02:00 #startmeeting glance 14:02:00 o/ 14:02:01 Meeting started Thu Dec 5 14:02:00 2013 UTC and is due to finish in 60 minutes. The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:03 yo yo! 14:02:05 The meeting name has been set to 'glance' 14:02:09 hi 14:02:53 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:02:56 meeting agenda ^^ 14:03:55 okay, I guess let's get rolling 14:04:21 #topic project status meeting updates 14:04:32 Icehouse 1 has been cut 14:04:37 w0000t 14:12:05 thanks for all the last minute patches, bugfixes, reviews folks 14:12:05 thank you markwish 14:12:06 yeah, thank you all for being so helpful 14:12:06 if your blueprint got deferred from I-1, know that its just becuase we had such a short time between the summit and I-1 14:12:06 o/ 14:12:06 and I-2 is ready for any spillover right now so let's keep at it 14:12:06 o/ 14:12:06 #link https://launchpad.net/glance/+milestone/icehouse-1 14:12:06 not much else to report from the project meeting 14:12:07 I'm still waiting to hear about mordred's plan for staging major python glanceclient releases 14:12:07 unless I just missed the email 14:12:07 I promose. I'm going to write it soon 14:12:07 hopefully we should be able to start implementing said plan next week 14:12:07 I thought about it in my brainhole on the aeroplane 14:12:07 haha 14:12:07 that is a good place for thinking 14:12:07 #topic checking in with the review backlog 14:12:07 As you guys recall, we've been trying to reduce our review backlog to make reviews more manageable and increase our responsiveness 14:12:07 let's see how we've been doing 14:12:08 #link http://russellbryant.net/openstack-stats/glance-reviewers-30.txt 14:12:08 (you should skip to the bottom of that one) 14:12:08 #link http://www.russellbryant.net/openstack-stats/glance-openreviews.html 14:12:08 o/ 14:12:08 we're doing somewhat better 14:12:08 Queue growth in the last 30 days: -3 (-0.1/day) 14:12:08 hmm 14:12:08 how much of that is auto abandons? 14:13:20 #link https://review.openstack.org/#/q/status:abandoned+project:%255Eopenstack.*glance.*+branch:master,n,z 14:13:38 so not much better then 14:14:04 but in lot of cases the committer has not gotten back to the reviewers comments 14:14:24 iccha: +1 14:14:27 the cases we should worried about are where we neglected 14:15:19 yeah a number of these have +2s 14:15:51 I wanna do another plug for this shortcut/bookmark 14:15:53 #link https://review.openstack.org/#/q/status:open+project:%255Eopenstack.*glance.*+branch:master+label:CodeReview%253D2+-label:CodeReview%253D-1+-+label:CodeReview%253D-2+-label:Approved%253D1,n,z 14:15:56 ameade: yep, however, the owner didn't address the comments of -1 14:16:00 +1 flwang 14:16:03 I call it "Needs one more" 14:16:12 https://review.openstack.org/#/c/37196/ 14:16:12 Its pretty low right now, which is great 14:16:40 I think its a good one to keep in mind, since it will improve our response time on things that already seem to be good enough to one of us 14:16:52 markwash: may I tag icehouse-1 now ? 14:16:54 thanks for identifying the patch ameade , now u can review it :p 14:16:55 ameade: it's abandoned by himself 14:17:07 * ttx hijacks meeting 14:17:30 ameade: (ttx) are you happy with all your critical bugfixes being in? or is there still one missing? 14:18:06 markwash: I see nothing targeted to i1 left 14:18:09 markwash: i think flwang and zhiyan wanted to talk about the image property quotas and the user experience 14:18:19 but everything is in 14:18:34 then ttx I think we're good 14:18:39 ameade: no big deal to tag a milestone where bugs survived anyway 14:18:45 ameade: thanks for mentioned that :D 14:19:59 just to close out the review status: It looks like we've stopped the queue from growing, but we've still got a lway to go. . 14:20:15 markwash: +1 14:20:18 amen 14:20:45 I'd like to save some room today to talk about blueprint organization, see if there is anything we can do to improve on the current situation 14:20:56 but before that, let's do some semi-open discussion 14:21:06 #topic image property quotas 14:21:21 ameade, flwang, zhiyan: ^^ ? 14:22:20 markwash: i have a little bit concern about the scenarios that before we set the quota for properties, there are some existed quota exceeding images 14:22:43 markwash: do you think it's ok or it should be take care by admin/deployer 14:22:57 flwang: that's a deployer's responsibility 14:23:06 hmm, we probably cannot address it with a migration at all 14:23:07 i think the default quotas are very large 14:23:32 just to be clear, it shouldn't break things if there are existing things over the quota 14:23:43 but one question I have, if the # of props exceeds the quota, can you at least remove properties? 14:23:58 any operations on an image must result in putting it backunder the quota 14:24:08 gotcha 14:24:11 markwash: so just removing 1 prop if you are 2 over will not work 14:24:16 and do we have any plan to add the quota for locations number? given the original goal of this bug is to avoid generating big load for the database 14:24:18 so you can remove N - Q properties 14:25:04 flwang: we should probably make a task to review other places where quotas should be applied 14:25:07 but you know, the location table has 'value' and 'metadata', two TEXT (64k) columns, but I didn't see we address it firstly 14:25:08 would it make any sense to have a "migration" that just logs if there are any images over the configured quota? that's a little silly I guess 14:25:18 rosmaita: yep, +1 14:25:31 rosmaita: that's what I wanna highlight 14:25:48 flwang: makes a lot of sense 14:26:02 markwash: ameade currently we don't allow enduser remove N-Q props 14:26:03 flwang: good point, i just came across the ones we've got when working on something else, not from a systematic analysis 14:26:04 flwang: good catch 14:26:44 rosmaita: i just follow up your original point of the bug :) 14:26:54 seems like a great #action item :-) any volunteers? 14:27:05 flwang, you've already got some context here. . . 14:27:18 markwash: ok, I can take it 14:27:24 +1 14:27:26 zhiyan: it should if the result of the transaction is under quota...or are you saying that doesnt work? 14:27:39 given ameade has done a lot of excellent work 14:28:05 #action flwang review the api for more items that should be under default quota/size restrictions and file bugs for anything that needs more work 14:28:22 markwash: yes, sir 14:28:33 flwang: thanks! 14:29:06 ameade: we can't remove the exceeded part 14:29:24 I think image sharing is next, is that you rosmaita? (as soon as we've tied up the last loose ends with quotas) 14:30:28 markwash: yes 14:30:39 okay, any last thoughts on quotas for today? 14:31:01 yes 14:31:09 zhiyan: I can dig into that later if youd like 14:31:40 should we contact with keystone team to set the quota in keystone given that's the right way to do that 14:32:01 i'm not sure the status of the bp in keystone 14:32:10 there has been some discussion about that recently 14:32:14 anyone we can contact? 14:32:15 ameade: sure. (actually i have wrote it in my comments in your tag quota change) 14:32:35 I'm not sure its the right way 14:32:43 1) there has been some significant pushback 14:32:55 2) the proposed mechanism is actually a push notification from keystone to us, IIRC 14:33:15 zhiyan: ah yes, it sounds like we are on the same page...so you are mostly concerned with it being a weird user experience? 14:34:00 markwash: got, then we can do that as we're doing now 14:34:22 flwang: yeah, I think its a good point to follow up on next meeting though, after the ML thread has mostly shaken down 14:34:25 * markwash looks for link 14:34:27 until it's ready 14:35:20 ameade: a little tbh, i think. 14:36:13 zhiyan: i totally agree, I could not figure out how to enforce it better with the current way the domain model works 14:36:14 flwang: ah looks like that topic is supposed to be discussed at next week's project meeting 14:36:40 zhiyan: it's kind of all or nothing unless we hit the db and check if the number of properties has decreased 14:36:52 markwash: ok, i can contact some keystone core to get more details 14:37:05 flwang: I think most of the details are linked from the ML thread 14:37:15 as a starting point 14:37:32 markwash: ok, will dive into the mail list :D 14:37:59 #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/020799.html 14:38:24 ameade: I'd like to take a look at that, maybe there is time to refactor the domain a little bit to make that less awkward 14:38:26 cool,thx 14:38:40 lets move on for now 14:38:46 #topic image sharing (rosmaita) 14:38:47 sounds good 14:38:58 i don't have much to say, just want to be in on writing the BP for image sharing enhancements, when whoever wants to work on it has time 14:39:06 * iccha making mental note to talk about more awkward stuff later 14:39:37 so i was basically wondering if anyone was working on it yet 14:40:26 my guess is we need a little more direction there 14:40:50 ok, i can put something together to get discussion started for next meeting 14:41:00 I'm not sure we ended up with much of a plan, there were some unsolved problems in both the incremental and non-incremental approaches 14:41:07 markwash: yep, rosmaita, it would be nice if you can highlight some direction 14:41:14 rosmaita: +1 14:41:19 ok, you can action-item me 14:41:42 #action rosmaita schedule a discussion for future plans for image sharing improvments 14:42:00 rosmaita: I can support you if you need any help 14:42:28 flwang: thanks, i will let you know when i have something to look at 14:42:34 all right, next topic is blueprint organization 14:42:36 may not be before next meeting, though 14:42:50 any other image sharing thoughts ? 14:43:14 roamaita: sure, you can catch me easily :D 14:43:41 happy to participant in deisgn discussion 14:44:27 #topic blueprint organization 14:44:52 #link https://blueprints.launchpad.net/glance 14:45:21 I think that link sort of speaks for itself in terms of a problem statement 14:45:50 there are 85 results in the list, mostly undefined 14:45:53 yes it does 14:45:55 *priority 14:46:27 I would love it if our blueprint system were something that helped clarify thinking about what we're working on, but honestly it mostly seems to confuse me 14:46:49 I dunno if anyone here has had better luck with blueprints when working with another project? 14:47:42 looking at other projects like https://blueprints.launchpad.net/cinder/+specs?memo=75&start=75 14:47:50 all seem to have some undefined stuff 14:49:13 maybe our step is to see what is there in our undefined and close out duplicates ? 14:49:49 it is ok to have some undefined cause it can serve to be an idea dump place, but as and when blueprints get added we maybe discuss in our meetings next bps proposed for the week? 14:49:57 i am just giving random suggestions here 14:50:06 random suggestions appreciated! 14:50:28 i think it's helpful when the BP has a full spec attached 14:50:32 with some use cases 14:50:47 and there are some which already have code submitted 14:50:48 https://blueprints.launchpad.net/glance/+spec/glance-cache+unittests 14:50:51 but are not approved 14:51:10 I'm trying to think if there is any way to set up a workflow there with bookmarks, sort of like dealing with the difficulties of reviews 14:51:24 iccha: yep, i think we should avoid this kind of stuff 14:52:08 markwash: +1 on workflow 14:52:10 if the bp is not approved, we should poke it before reviewing 14:52:21 one thought that I keep coming back to, is it might help if we required patches to be linked to approved blueprints or accepted bugs. . but I think we're pretty far from being able to do that in an automatic fashion 14:52:44 maybe as reviewers it is our responsibility? 14:52:47 and by required, I mean, I would make a review bot that -1s anything that is not so linked 14:53:19 but that idea does have a number of problems I suppose 14:53:38 for one, I don't really mind if people want to include a patchset to stand in for the spec for a blueprint 14:53:52 and for another, we get a lot of good stuff from bugfixes for bugs that never get triaged 14:54:07 (bug organization is another similar topic) 14:54:19 but bp is different from bug 14:54:21 sometimes i end up triaging after looking at patch :( 14:54:35 flwang: true 14:55:05 flwang: I guess I worry, if we required more from bp-linked changes than bug-linked changes, folks would just register enhancements as bugs 14:55:09 iccha: good point, i will follow 14:55:40 but maybe that is not a big concern 14:56:07 any open discussion stage today? 14:56:18 anyone interested in following up on this topic next week or a bit later? It might benefit from some solo thinking 14:56:25 flwang: sure 14:56:28 +1 14:56:32 #topic open discussion 14:56:36 e too 14:56:44 *me 14:56:53 trying to get details on locations etc for the glance mini summit in DC area markwash 14:57:01 markwash: i'm thinking the impact of container technology for Glance 14:57:15 ashwini: thanks! let me know any updates or if there is anything you need from me 14:57:23 flwang: tell us more 14:57:32 flwang: interesting topic for sure :-) 14:57:45 markwash: will do, we should probably have a quick phone call on it so hash out some other details 14:57:50 so one thing i was trying to get at earlier with reviews, can we do anything to help patch submitters with these patches that go abandoned? 14:58:04 i think it's a cop out to just say it's on them and ignore the issue 14:58:40 ameade: I agree. it should be easy to mine the gerrit history for patches that were abandoned with no reviews 14:58:56 we could go through and resubmit ones that seem valuable 14:59:09 ashwini: sure, sometime today? or is that too soon? 14:59:20 such as docker, it will consumer image directly instead of using Glance for now 14:59:25 s/resubmit/restore/ 14:59:31 thats what i do sometimes, i go to abandoned aotches and say i apoligize that they got ignored and request reviewwer to restore them 14:59:31 markwash: can you think of something we can do to help in the long run? i'm sure this is also something other project deal with 14:59:54 so given container/docker is so hot, i'm wondering if we should do some investigation to embrace it from the glance POV 14:59:56 maybe the auto-abandon system is flawed 15:00:00 markwash: today is fine with me, my afternoon is mostly open 15:00:04 given it's the next big star 15:00:08 ameade: the thing we really need is to get our review queue down if at all possible 15:00:08 flwang: sounds like interesting idea 15:00:53 flwang: I'm interested in that. . especially what kinds of changes we might need to make. . it would be really good to see ways in which we are specific to vms right now that we could generalize 15:00:56 maybe the future 15:01:00 or if there are other changes that make sense 15:01:05 markwash: yeah that would solve future problems 15:01:12 markwash: exactly 15:01:22 markwash: i'll take an action item to look through old reviews 15:01:29 ameade: ah yes, but you're right, the problems of the past need our attention 15:01:40 markwash: for now, we are targeting VM, but container is target to application 15:01:57 so maybe we should adjust our mission/goal to do some change 15:01:59 markwash: also not sure if i made it clear will take action item on blueprint process 15:02:20 hmm, we might need to vacate 15:02:25 it is past time 15:02:29 thanks everybody! 15:02:34 \o 15:02:34 #endmeeting