02:04:41 #startmeeting zaqar 02:04:43 Meeting started Tue Jun 27 02:04:41 2017 UTC and is due to finish in 60 minutes. The chair is flwang. Information about MeetBot at http://wiki.debian.org/MeetBot. 02:04:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 02:04:46 The meeting name has been set to 'zaqar' 02:05:02 #topic roll call 02:05:04 o/ 02:06:23 hi 02:06:33 hi guys 02:07:08 gecong_: thanks for joining 02:07:26 thanks 02:08:09 hi 02:08:14 wanghao: hey 02:09:46 wanghao: gecong_: here is the agenda https://etherpad.openstack.org/p/zaqar-meeting-agenda 02:10:14 #topic service queue spec 02:10:33 ok 02:10:40 I have asked theve, zaneb and flaper87 to review this spec 02:10:48 somebody did, but somebody didn't yet 02:11:14 we have 1 month before the milestone of pike-3 02:11:25 okay, I talked lei-zh yesterday about the POC patch, and there is a requirement to Zaqar. 02:11:38 wanghao: cool, can you talk more? 02:12:03 searchlight want Zaqar can support to send messages to many queues one time. 02:12:07 like boradcast 02:12:46 how? 02:12:47 it will send a list of projects in X-SERVICE-DELEGATED-PROJECT-ID. 02:13:18 and Zaqar need to post messages to those projects one by one. 02:13:20 and then zaqar do the magic? 02:13:25 NO 02:13:36 that totally out of the scope of zaqar 02:13:56 emm, I think so 02:14:28 yep, I would say "sorry, searchlight, Zaqar can't do that" 02:14:42 it will make the API dirty IMHO 02:14:57 technically, we can do it, but we shouldn't 02:15:14 I agree 02:15:22 okay, I will talk about this with lei-zh 02:15:28 I won't say I don't care the feature of service queue, but if we need to introduce such a ugly feature into zaqar just to support service queue, i will totally reject the service queue spec 02:16:09 so in short, no, we can't support that 02:16:18 got it. 02:16:36 I agree too. 02:17:04 I will push zaneb and therve to revisit the spec and hopefully we can get an agreement before next meeting 02:17:12 bascially, the case is when admin create a flavor, searchlight need to notify every project. 02:17:14 okay 02:17:36 got it 02:17:44 and another bad thing for now is, we still don't receive any feedback from horizon team, those interns working on this horizon feature 02:18:07 so wanghao, could you please reply that thread and push horizon team? 02:18:22 if they don't really care about this feature, please let us know 02:18:26 flwang: okay 02:18:31 wanghao: thanks 02:18:58 I got strong interest from the Horizon PTL when we met at Boston 02:19:13 hence why I push this feature after that 02:19:41 but I can't see much support from them now, so I'd like to confirm if they're still interested in this 02:19:52 yeah 02:20:43 anything else for the service queue we need to talk? 02:21:04 not from me 02:21:30 I haven't any question now 02:22:31 #topic notification policy 02:22:59 okay, emm, this I have committed a patch without ut yet. 02:23:23 I will review it later 02:23:31 thanks 02:23:47 wanghao: I didn't go through the spec yet, but I will do it today for sure 02:23:51 sorry again for the delay 02:23:59 flwang: np, never mind 02:24:23 and I will test it to ensure it work well 02:24:35 the only concern like I mentioned is we're adding more and more reserved keys into the queue metadata 02:25:06 yes, now we add a lot of things in metadata 02:25:10 we may need to review all the reserved metadata keys and decide the long term strategy for this 02:25:39 yes 02:26:05 maybe we can consider to introduce some new resource for queue 02:26:19 that we can extract some metadata from queue. 02:26:42 good idea 02:27:41 maybe I can do something 02:28:17 you mean new attribute/field for queue data model? 02:28:18 nice! 02:28:32 flwang: kind of 02:28:38 wanghao: could be 02:29:42 we should keep this in mind for now and revisit it in Queen 02:29:51 emm, agree 02:29:56 got it 02:30:04 because currently, all users just use zaqar client to access zaqar api 02:30:20 and with distil client, user actually don't really care how the data is saved 02:30:25 so not too bad 02:31:14 and before we can see more strong requirements, let's keep an eye and revisit later 02:31:32 emm, ok 02:31:33 okay 02:31:38 wanghao: back to the notification policy spec, i really want to get it in Pike 02:31:40 ok 02:31:51 flwang: yeah, me too 02:31:52 so let's work on it and make it happen 02:31:57 cool 02:32:13 anything elese? 02:32:31 we plan to support only one backoff function in Pike, so it's not hard. 02:33:06 wanghao: ah, i see. 02:33:30 so we will mainly implement the framework and then support policies one by one, right? 02:34:02 yes, 02:34:04 wanghao: cool, i see. 02:34:06 yeah 02:34:29 anything else? 02:34:38 no 02:34:40 #topic dead letter queue 02:34:43 is there anything I can do fot that 02:34:54 gecong_: if you're willing to help 02:35:03 maybe you can help the dead letter queue :) 02:35:10 yes I will 02:35:14 oK 02:35:18 sorry, wanghao, i'm grabbing gecong_ for my feature ;) 02:35:24 np 02:35:26 haha 02:35:37 np 02:35:47 dead letter queue spec has been there for a long time 02:35:52 due to many reasons 02:36:02 I am very happy 02:36:06 i'd like to get it done it pike to suppor the mongo backend 02:36:17 as you can see in the spec 02:36:40 yeah 02:36:45 I think spec is almost closed, not big issue for me. 02:36:48 the simple idea is just move the message from the original queue to the dead letter queue 02:36:56 wanghao: thanks 02:37:14 I have reviewed it 02:37:29 so that said, i'd like to merge it asap and focus on the code 02:37:39 for tiny issues, we can address them during the code review 02:37:46 +1 02:37:50 and update the spec later 02:37:51 +1 02:38:07 you know, the way of spec is good, but it's not really efficient 02:38:18 we can't get a perfect design 02:38:20 yeah, some details in code. 02:38:36 we will make some mistakes, leave some bugs 02:38:50 but IMHO, it's fine, if we can get feedbacks, we can fix them 02:38:58 if there is anything need for me to do ,please let me and gengchc to help you 02:39:04 if we can't get feedback, them it's nothing, right ? ;) 02:39:06 :) that's always happend 02:39:31 gecong_: gengchc: so you're different people? 02:39:37 yes 02:39:38 shit, i think they're same ids :D 02:39:46 fantastic 02:39:52 I would like to introduce 02:39:58 nice 02:39:59 to your gus 02:40:11 you guys come from zte? pls remind me your company name 02:40:20 gecong_: pls pls pls 02:40:23 yes , he is also from zte 02:40:34 pls introduce yourselves 02:41:22 I'm really sorry for missing gengchc 02:41:30 gengchc: waves from NZ 02:41:34 I am gengchangcai from zte company,i am interesting in zaqar. 02:41:35 please wait a minutes 02:41:46 We want to introduce zaqar in our project, but we do not know what aspects zaqar is more suitable for. 02:42:26 gengchc: as a service for your private cloud solution or for public cloud? 02:42:55 for private cloud 02:43:13 gengchc: ok, cool 02:43:59 now we're a small team, we do need more resources to make zaqar better 02:44:07 so really appreciate for your joining 02:44:14 yes, welcome 02:44:22 welcome 02:44:33 thank you 02:44:34 I'm Feilong Wang, and now I'm serving the PTL for 4th cycle 02:44:48 I was working for IBM and moved to NZ 3 years ago 02:45:12 now i'm working on a public cloud based in New Zealand as the dev manager 02:45:33 and I also worked on Glance for the last 4 years 02:45:46 wanghao: your turn 02:46:02 I have joined your wechat. 02:46:05 I'm wanghao, now working for Fiberhome, and jumped from Huawei one years ago. 02:46:16 My wechat is 耿常才. 02:46:32 gengchc: oh, cool, i will add you to our group 02:46:53 and I focus on Zaqar and Cinder for a long time. 02:47:16 gengchc: i can't find your name :( 02:47:26 nice to meet you, feilong and wanghao 02:47:34 cool, we can talk more offline 02:47:40 now let's continue the meetint 02:47:52 ok 02:48:18 gecong_: wanghao: pls revisit the dead letter queue spec and let's merge the spec soon 02:48:27 and then i'm going to focus on the code for mongo backend 02:48:27 flwang: sure 02:48:34 I am sorry,my wechat is gcc5780437969 02:48:35 np 02:48:54 and gecong_, you can work on the swift backend or redis, if you're interested in 02:49:02 np 02:49:34 the last topic for today meeting is the Sydney summit topics 02:49:49 we need to submit a topic 02:50:05 #topic Sydney summit session 02:50:28 i was thinking it would be nice if we can present the service queue feature with searchlight team and horizon team 02:50:37 yes, me too 02:50:42 but I'm not too sure if we can achieve that in time 02:50:56 maybe just searchlight? 02:51:04 so wanghao pls reply the email and push horizon guys to get feedback 02:51:14 em, sure 02:51:27 without horizon support, it's not really attractive, TBH 02:51:41 emm, I see 02:51:52 but meanwhile, we need to brainstorm if there is another topic we can propose 02:52:36 gecong_: gengchc: do you have any customer requirement about zaqar? 02:52:58 why ZTE are interested in zaqar? 02:53:28 for now ,not yet 02:54:03 i see, because more of China customers are still in the stage of virtualization+, IMHO 02:54:19 they just want to play with cloud, but they're not really sure how to use it 02:54:34 and what's the workload they want to put on cloud 02:54:45 There is not yet, but we are studying how to use zaqar, the boss is very interested in it. 02:54:52 and most of the workload just traditional legacy application 02:55:07 not really distributed, cloud app 02:55:39 yep, as you can see, all public cloud have queue/msg service 02:56:34 anyway, gecong_, gengchc I'm really happy to see ZTE it putting resource on zaqar and any contribution for the project will be really welcomed 02:56:48 is zaqar supported distributed nodes? 02:56:54 all the people within the team are very friendly and positive 02:57:00 feel free ask any question 02:57:07 gengchc: sure 02:57:27 gengchc: do you mean the distributed data storage of message? 02:57:41 ok, we have 3 mins for open talk 02:57:47 #topic open discussion 02:58:29 gengchc: gecong_: any question? 02:59:30 okay time is up 02:59:40 let's back to zaqar channel 02:59:42 #endmeeting