21:00:03 #startmeeting Zaqar 21:00:04 Meeting started Mon Sep 1 21:00:03 2014 UTC and is due to finish in 60 minutes. The chair is flaper87. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:07 The meeting name has been set to 'zaqar' 21:00:09 #topic Roll Call 21:00:15 * flaper87 o/ 21:00:37 * vkmc o/ 21:00:41 vkmc: flwang ? 21:01:42 kgriffs: roll call 21:01:44 :D 21:01:50 o/ 21:01:56 good boy 21:02:05 #topic Actions from last meeting 21:02:11 #link http://eavesdrop.openstack.org/meetings/zaqar/2014/zaqar.2014-08-25-15.10.html 21:02:25 kgriffs to land redis patch 21:02:29 I believe that's done 21:02:31 right ? 21:02:41 pretty much 21:02:48 the ascii thumbs up said so 21:02:49 #info Base redis patch has been approved 21:03:08 I am in the middle of working on expiring claims and messages 21:03:10 kgriffs: anything critical left before we can mark that work as done? 21:03:18 kgriffs: roger 21:03:22 ran into a snag with trying to keep the stats counters up to date 21:03:25 so, I have to fix that 21:03:32 kk 21:03:39 kgriffs to publish rough benchmark numbers, more later with redis numbers 21:03:46 and then also add a script that can be called from cron periodically to trigger the driver's GC method 21:04:02 #info Bench numbers were sent to the mailinig list. No feedback for now 21:04:11 otherwise, there are a few lower-priority work items on the blueprint we could slip if needed 21:04:31 kgriffs: lets split them 21:04:41 flaper87: actually, did get some feedback from Mr. Pipes on that 21:04:54 kgriffs: yeah but he asked to test with keep-alive 21:04:58 he was wanting to see the result of turning off keepalive 21:05:00 ywah 21:05:02 anyway 21:05:02 he didn't mention anything about the numbers 21:05:04 right ? 21:05:10 not really iirc 21:05:32 I should've said: No *useful* feedback :P 21:05:51 anyway, I think we should keep sending those emails 21:05:56 lets move on 21:06:12 k. I'd like to do a "Round 2" sometime this week once the redis driver is squared away 21:06:12 The agenda is pretty small this week too 21:06:22 kgriffs: +1 21:06:35 #action kgriffs to re-run benchmarks using the redis driver 21:07:09 #topic What checks should go to the API/Storage layer? 21:07:34 so, there are 2 patches pending for review that introduce some checks in the storage layer 21:07:46 1 is from wpf and the other one is mine 21:08:20 regardless on whether those patches are correct, I think we should have some *blendable* rules w.r.t where API - I mean, Zaqar's API - checks should go 21:08:23 for example: 21:08:38 #link https://review.openstack.org/#/c/117706/ 21:08:46 flaper87, yours has been merged IIRC 21:09:05 #link https://review.openstack.org/#/c/117706/3/zaqar/queues/storage/mongodb/pools.py,cm 21:09:09 vkmc: w0000t 21:09:12 :P 21:09:24 flaper87, it's not in the review queue... so :o 21:09:49 In order to enforce this, wpf got an instance of `flavors` collection and is doing queries right from the storage driver 21:10:05 there's a way to do this from the wsgi transport 21:10:17 there are several questions we should ask ourselves 21:10:32 but the one I want us to answer now is where does that check belong 21:10:51 Regardless on whether it's more performant to do it in the storage layer or not 21:11:10 The reason I'm putting performance aside now is because I'd like the code base to be consistent 21:11:27 and we should strive to do that. There will be cases where that won't be possible 21:11:49 Thoughts so far? 21:12:12 The other thing to think about is that storage drivers are multi-version 21:12:20 by "that check" do you yours or wpf's? 21:12:26 that is, there's no 1:1 mapping between the storage driver and the transport 21:12:37 I meant wpf's 21:13:02 kgriffs: https://review.openstack.org/#/c/117706/3/zaqar/queues/storage/mongodb/pools.py,cm L104 21:14:38 knock knock? 21:15:03 looking 21:15:57 I think one sane thing to do is to keep API specific checks within the API 21:16:18 TBH, I'm really not sure what the right thing to do there is 21:16:26 hmmm 21:16:28 so, we should probably take more time and put more thoughts on it 21:17:06 I've been thinking about this more generally lately. Like, we don't do a lot of validation in our storage layer at the moment, but maybe we should 21:17:31 hmm, if IIRC in most reviews we always tried to delegate control to transport 21:18:01 letting storage to worry about storage only 21:18:12 we do perform queue existence checks in the storage drivers 21:18:25 one thing that has bitten us is mixing controllers 21:18:38 I think the storage driver ought to check anything that could cause it's data model to break 21:18:56 I agree with that ^ 21:18:56 so, we should probably decided if we're going to give more value to performance or consistency here 21:19:07 kgriffs: ++ 21:19:26 in our case performance is crucial 21:19:32 how much consistency would be affected? 21:19:51 vkmc: AFAICS, lots of it (with regard to API checks and stuff) 21:20:02 o/ 21:20:04 I mean, if we have the right rules in place, we'll still be consistent 21:20:12 please blame the bus :) 21:20:16 for example: storage layer checks its data model is not broken 21:20:33 that's a good way to put it and a good way to choose where things should go 21:20:35 flwang: >.> 21:20:42 stupid bus 21:20:51 yeah I think it's that is the best flaper87 21:21:44 #agreed Checks should stay in the data plane they belong too. Storage drivers must enforce their data model stays consistent 21:21:58 Does that sound right? 21:22:04 it does to me 21:22:09 kgriffs: flwang ? 21:22:40 sounds right 2me 21:22:47 ok 21:22:53 +1, storage driver should focus on the interaction with db 21:22:56 Also, I think this should go into our dev docs 21:22:59 vkmc: ? 21:23:01 :D 21:23:03 instead of involving too much logic 21:23:32 #action vkmc to add checks enforcement rule to our development docs 21:23:34 :D 21:23:57 :) sure thing 21:24:05 ok, lets move on 21:24:08 #topic Summit Sessions Proposals 21:24:23 You probably already saw this on the mailing list 21:24:26 I've created https://etherpad.openstack.org/p/kilo-zaqar-summit-topics 21:24:29 #link https://etherpad.openstack.org/p/kilo-zaqar-summit-topics 21:24:49 lets start adding proposals there so we can start getting feedback from the team 21:25:12 Lets add things that we're definitely going to get done 21:25:31 WE should use the summit to discuss things that require a f2f discussion 21:25:40 and are essential for Zaqar 21:25:49 kk 21:25:51 get messages by id removal is one, for sure 21:26:02 lol, yeah 21:26:08 vkmc: that could fall into one of our API sessions 21:26:16 kewl 21:26:21 which leads me to the next topic, if there's nothing else to add here 21:26:41 #topic Should we start discussiong API v2? 21:26:43 I"m wondering is there an operation session for this summit 21:26:53 #undo 21:26:54 Removing item from minutes: 21:27:11 flwang: we could have one if there's something relevant to discuss 21:27:16 there's an OPs session 21:27:24 actually, I'm not sure if that talk got accepted 21:27:28 kgriffs: do you know if Oz 21:27:34 kgriffs: do you know if Oz's talk got accepted ? 21:28:01 i hadn't heard. I can find out. 21:28:06 kk 21:28:08 kgriffs: thanks 21:28:28 wrt v2 21:28:30 We could probably have an informal devops discussion at our pod 21:28:33 Catalyst IT will enable Zaqar asap 21:28:33 #topic Should we start discussiong API v2? 21:28:39 flwang: AWESOMEEEEEEEEEEEEEEEEEE 21:28:43 so we really need to get some ops experience 21:28:53 I don't want to talk about it unless we feel like we have the bandwidth to get it done during kilo 21:29:06 kgriffs: +1 21:29:06 I think we could have a goal to have a "community preview" of v2 for the kilo summit 21:29:31 If we want to remove message-by-id, we'll have to discuss v2 21:29:35 may I know what's the killer feature to distinguish the v1.1 and v2? :) 21:29:43 and then take the community feedback and finalize v2 in the next cycle 21:30:04 kgriffs: totally agreed 21:30:17 I'd like to give 1 full cycle without API changes to gather enough feedback 21:31:03 vkmc: flwang ? 21:31:17 +1 to that 21:31:31 +1, stable is always good for prod env :) 21:31:47 ok 21:32:11 #agreed lets not start working on new APIs. Lets give the community at least 1 full cycle to digest v1.1 before we start talking about v2 21:32:26 anything else on this topic? 21:32:57 I'll take that as a no 21:33:04 #topic Graduation status 21:33:07 #link https://launchpad.net/zaqar/+milestone/juno-3 21:33:17 so, the base patch for readis just landed 21:33:35 kgriffs: you said there are a couple of other patches that are still critical for this blueprint to be considered implemented 21:33:45 yeah 21:33:46 Do you think we can get them done this week? 21:33:58 Before FF 21:33:58 yes, I will have them by tomorrow or wed 21:34:02 awesome 21:34:09 otherwise we'll have to ask for a FFE 21:34:09 just to recap 21:34:12 the patches are 21:34:17 * flaper87 STFU 21:34:28 1. Garbage collection / expiration of claims, messages 21:34:48 2. Remove stats counters and just calculate them dynamically 21:35:04 that second one has to be done before GC...long story 21:35:23 then there are a few other work items on the bp that are "bonus" if we get to them 21:35:24 * flaper87 was going to ask if #2 is essential. It looks like it is 21:35:50 ok 21:36:22 #info Essential things missing in the redis patch are: 1. Garbage collection / expiration of claims, messages, 2. Remove stats counters and just calculate them dynamically 21:37:10 vkmc: updates on this one: 21:37:13 #link https://blueprints.launchpad.net/zaqar/+spec/api-v1.1-user-guide 21:37:24 I know there's a py33 issue on the configs one 21:37:41 * kgriffs has to leave in a minute 21:38:03 kgriffs: ok, thanks for the hard work on the redis patch 21:38:14 great work there (both of you) 21:38:16 my pleasure 21:38:17 thanks kgriffs :) 21:38:49 kgriffs: also, remember the TC meeting tomorrow 21:38:56 kgriffs: 20 UTC 21:38:59 kk 21:39:03 vkmc: so, updates ? 21:39:04 flaper87, that bp is targeted for K and will be started after we get some feedback from the community 21:39:22 targetted for k ? 21:39:30 flaper87, which is being done right now is https://blueprints.launchpad.net/zaqar/+spec/document-config-options 21:39:41 vkmc: https://blueprints.launchpad.net/zaqar/+spec/api-v1.1-user-guide is on Juno 21:39:46 Should I move it ? 21:40:45 vkmc: ^ 21:40:45 for what I discussed with kgriffs|afk... it should be moved it 21:40:52 s/it/ 21:41:35 oh ok, sorry. I must have missed that discussion 21:41:43 no problem 21:42:01 I moved it to k-1 21:42:14 the user guide for API v1 is in good shape 21:42:36 we're in a better shape now 21:42:38 awesome 21:43:01 Catherine did a great job and we updated it to fit our current goals :) 21:43:17 awesome, I'm very glad we did this back then 21:43:20 sweet 21:43:25 vkmc: thanks for leading the docs effort! 21:43:31 flaper87, no problem 21:43:42 anything else I/we should know w.r.t the Juno/Graduation status? 21:44:28 #topic Graduation Meeting 21:44:39 * flwang has to leave for a minute 21:44:43 * vkmc goes through graduation etherpad 21:45:06 Tomorrow at 20 UTC Zaqar will be reviewed for graduation 21:45:11 that's the first of 2 meetings 21:45:26 During the first meeting the graduation requirements are going to be revisited 21:45:35 It'd be nice if we all attend the meeting 21:46:15 count with my presence :) 21:46:30 awesome! 21:46:37 I'll be there too 21:46:42 In case some questions arise 21:47:06 I think we're not in bad shape. Some things could be better but I'm possitive about our status 21:47:06 thanks 21:47:27 Now, if there's nothing else to add here, I'll move on to open discussions 21:47:41 #topic Open Discussions 21:47:58 * flaper87 likes gummy bears 21:48:05 haha :) 21:48:06 * flaper87 is wearing new glasses 21:48:18 reading glasses? 21:48:32 yup 21:48:43 well, they used to be just for reading but things got worse 21:48:46 :/ 21:48:50 boo, that's a bummer 21:49:29 yeah 21:49:31 :/ 21:49:41 ok, I don't have any other personal and embarrasing thing to share 21:49:43 anyone ? 21:49:57 I'm just thinking if there is something missing for graduation 21:49:58 Who's wearing a superman underware today? 21:50:10 what is the status with Heat? 21:50:40 the status with Heat - and every other integrated project - is that they want us but they won't use us until we graduate 21:51:10 ok, but they want us... which is good 21:51:33 yeah, I believe zaneb updated Heat usescases with some of his ideas 21:52:15 that's cool 21:52:51 well, I think there is nothing else to bring up about our status 21:53:13 ok, lets talk about serious stuff 21:53:21 you should all watch True Detective 21:53:23 it's coool 21:53:29 I saw it 21:53:32 not as great as Breaking Bad but it's nice 21:53:38 vkmc: do you like it ? 21:53:41 and now I don't know what to watch :( 21:53:44 oh I loved it 21:53:53 DON'T SPOILE IT 21:54:00 I won't haha 21:54:04 I still have some episodes to watch 21:54:10 oh do you? DO YOU? 21:54:12 * flaper87 knows how to play the intro theme 21:54:28 ... in guitar 21:54:31 which episode is next? 21:54:46 I think 7th 21:55:04 oh in that one...! 21:55:06 :p 21:55:10 youuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu 21:55:14 don't youuu dare 21:55:25 hahaha nah I won't 21:55:31 I think I'll start watching The Wire 21:55:31 2 more great but different TV series 21:55:36 I heard great comments about it 21:55:37 Undatable: SOOOOOOOOOOOOOO FUN 21:55:51 Mom: Not as fun as undatable but it's nice 21:56:03 * flaper87 writes The Wire down 21:56:21 9.4 in IMDB ;) 21:56:29 that must be good 21:56:36 or IMDB just sucks 21:56:36 * vkmc looks for Undatable and Mom 21:56:38 :P 21:56:50 true detective has 9.3 21:56:53 you tell me 21:56:54 hahaha 21:56:55 http://www.imdb.com/title/tt2788780/ 21:57:20 sounds like fun 21:57:40 vkmc: https://www.youtube.com/watch?v=SuAGmC5g2_o 21:57:49 is it as How I met your mother? 21:57:57 (please say no) 21:58:09 nope 21:58:23 * vkmc sighs 21:58:27 at least I don't think it is 21:58:29 :P 21:58:34 do you like How I met your mother? 21:58:40 not really 21:58:55 * vkmc has found a friend in flaper87 21:59:23 (sorry to all HIMYM fans) 21:59:34 :D :D :D :D 21:59:37 screw them 21:59:39 * flaper87 hides 21:59:42 lol 21:59:42 ok, time's up 21:59:45 meeting is over! 21:59:47 best open discussion EVER! 21:59:51 Thanks everyone 21:59:53 lol yeah 21:59:54 #endmeeting