21:08:35 #startmeeting Zaqar 21:08:36 Meeting started Mon Feb 22 21:08:35 2016 UTC and is due to finish in 60 minutes. The chair is flwang1. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:08:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:08:39 The meeting name has been set to 'zaqar' 21:08:40 sorry for the late 21:08:44 was in a meeting 21:08:53 #topic roll call 21:08:55 o/ 21:08:58 o/ 21:09:10 o/ 21:10:41 flwang1: so, let's move on 21:10:54 Eva-i: cool 21:10:59 #topic code review 21:11:16 i think we did a great job given our team size 21:11:16 Please review my websocket binary patch =) 21:11:21 Eva-i: haha 21:11:37 Eva-i: yep, that's the one on my list, I just need a test to give it a +2 21:12:04 what in my mind currently is : 21:12:12 1. binary websocket 21:12:20 2. more reserved attributes of queue 21:12:25 flwang1: thank you, ask me if you need some help with testing 21:12:28 3. TTL subscriptions 21:12:32 4. metadata update 21:13:26 ok 21:13:48 #link https://review.openstack.org/265723 21:14:01 #link https://review.openstack.org/270464 21:14:10 #link https://review.openstack.org/280941 21:14:30 https://review.openstack.org/256978 21:14:56 ryansb: i know you have reviewed most of the patches, but it would be nice if you can revisit the binary websocket one https://review.openstack.org/256978 thanks 21:15:11 Yeah, sure thing 21:15:19 wasn't sure if that was ready for another round 21:16:04 i see 21:16:20 * ryansb promises to write more zaqar patches and not just review things 21:16:31 m-3 is coming, we need to make sure those above patches can be merged 21:16:36 yup 21:16:40 ryansb: ack :) 21:17:12 ryansb: but you're very effective at reviewing things =) 21:17:31 so it's okay 21:18:38 anything else for code review? 21:18:46 or anything patch we need to discuss? 21:19:05 not from me 21:19:46 nope - I got a dev env setup for the ansible-zaqar stuff though 21:19:47 #topic zaqar UI 21:19:58 ryansb: awesome 21:19:58 * Eva-i realised that she forgot to invite huawei guys to the meeting 21:20:18 Eva-i: it's fine, it's 5 am of China 21:20:25 ah 21:20:26 so most of the guys are in sleep i think 21:20:59 yeah, I'd only expect them to be at the other meeting 21:21:09 oki 21:21:13 for zaqar UI, we have made some progress 21:21:22 \o/ 21:21:31 queue list, queue crate and queue update and delete are coming 21:21:36 horizon guys are working on that 21:21:40 I tried zaqar-ui and noticed few bugs 21:22:08 Eva-i: cool, i'm thinking if we should create a launchpad for zaqar-ui 21:22:10 is it okay that we don't have a place for reporing zaqar-ui bugs? 21:22:19 flwang1: I think it would be nice 21:22:40 #action flwang will create a zaqar ui lauchpad place :) 21:23:31 I'm pretty sure this place will be occupied by me 21:24:46 Eva-i: awesome :) 21:25:54 flwang1: good job on working on zaqar-ui 21:26:22 Eva-i: not me, thank for horizon guys 21:26:37 #topic puppet/ansible 21:26:45 flwang1: they too 21:27:08 k, so ansible update is "wow OSAD is even slower than devstack" 21:27:20 thanks for the help from tripleo team, our puppet zaqar work almost done 21:27:31 ryansb: haha 21:27:39 nice 21:28:00 ryansb: based on current status, how long do you think we will take to get a workable ansible? 21:28:33 at least a couple weeks 21:29:12 ryansb: do you think a newbie can help to speed it up? like me? 21:29:35 we(catalyst it operation guys) are keen to use ansible(yep, not puppet) to deploy zaqar 21:30:13 right now I'm just working on getting what's there working so I can document 21:30:20 after it's documented, maybe 21:30:36 but right now I think anyone new would just be baffled 21:31:21 ryansb: hah, ok, just like me know if you need any help 21:31:32 ryansb: and don't forget, we can get support from ansible team 21:31:38 will do :) 21:31:40 that's a nice team 21:31:45 like horizon team 21:32:11 i would say that again, horizon team is best team in openstack community except zaqar team :D 21:33:33 =) 21:34:51 #topic open discussion 21:34:58 anything we need to discuss today? 21:35:38 maybe expiration of things in redis 21:35:39 I don't have anything 21:35:50 but maybe it's hard to discuss in real time 21:36:32 ok, I don't have anything 21:37:07 what did you want to ask? 21:37:15 I'd like to at least start to ponder it 21:37:31 ryansb: some resources in our redis storage driver do not expire 21:37:48 hrm, not so good, since redis needs everything to be in memory 21:37:48 ryansb: let me share a link to a patch with our discussion 21:37:55 sure, that'd be awesome 21:38:16 ryansb: here: https://review.openstack.org/#/c/276548/ 21:38:28 thanks 21:38:55 I'll check it out 21:38:59 ryansb: thank you too 21:39:41 so we need to find some solution 21:40:35 that's all I wanted to say 21:40:55 k, I don't have anything else 21:42:53 yep, that one is hard 21:42:58 i mean https://review.openstack.org/#/c/276548/ 21:43:04 but we need to fix it in Mitaka 21:43:18 that's on my list, but anybody is welcome to submit a patchset 21:43:40 ryansb: oh, maybe we can discuss if we should have a default TTL for subscription 21:43:56 ah, sure 21:44:21 I think a default of an hour would be reasonable 21:44:22 ryansb: TBH, i'm not really sure if we should have a default TTL 21:44:40 so you'd rather have TTL be a required field? 21:44:41 ryansb: i don't have any preference for the value 21:44:58 flwang1: i'm not sure too 21:45:52 ryansb: when i designed it, i think subscription is a different resource than message 21:46:03 just like why i really like a permanent subscription 21:46:14 so it's designed as required field 21:46:32 Hm, that way users have to explicitly say "permanent" 21:46:34 I see 21:46:48 but now, i'm not sure if i was correct 21:47:07 and we don't have user feedback 21:47:24 so i would prefer to keep it simple 21:47:34 more flexibility 21:47:48 I see 21:47:53 user can set or not 21:48:43 I think I found what can possibly go wrong with permanent subscriptions 21:48:44 but the bad thing is, user may miss it and still expect to be notified after subscription expired 21:49:03 Eva-i: queue delete? 21:49:32 flwang1: no, I'll try to explain use case 21:49:40 *explain case 21:50:06 we may need a check for queue delete to check if there is any subscription on that queue 21:50:51 flwang1: sorry, I still haven't wrote blueprtint for queue lazyness with subscriptions. If queues will be lazy, there will be no problem with deleted subscriptions. 21:52:02 Eva-i: that's right 21:54:27 the case: cloud admin has Zaqar and there are users which cloud admin can't control. The users have created many permanent subscriptions. One day there became so many subscriptions, so it loads server with Zaqar much. The cloud admin suspects some permanent subscriptions are unused. How cloud admin can delete unused subscriptions? Can he figure out which ones are still being used? 21:54:57 can this case be real? 21:55:02 maybe I just don't understand something 21:59:16 okay, time is up, we can think about it later 21:59:43 Eva-i: let's discuss it offline 21:59:52 thank you guys 21:59:57 thanks 22:00:01 let's back to zaqar channel 22:00:06 #endmeeting