08:08:06 #startmeeting multisite 08:08:06 Meeting started Thu Jan 21 08:08:06 2016 UTC. The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:08:06 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:08:06 The meeting name has been set to 'multisite' 08:08:19 #topic rollcall 08:08:21 #info Ashish 08:08:26 #info joehuang 08:08:29 #info dimitri 08:08:31 #info zhiyuan 08:08:47 Zhipeng, you have a good message for multisite 08:08:55 could you share with us 08:09:09 yes, dear multisiters 08:09:26 Openstack foundation just published its very first NFV report today 08:09:47 and in it, Multisite is one of the two projects that is mentioned 08:09:54 in a dedicated section 08:10:04 fantastic! 08:10:04 our work have been detailed described 08:10:21 Awesome guys. Congrats al 08:10:22 the editor actually talked to me during last year's opnfv summit 08:10:23 all 08:10:29 yes, our work has be recognized in the whitepaper 08:10:34 i guess the talk pay up quite nicely :P 08:10:37 #link http://www.openstack.org/assets/telecoms-and-nfv/OpenStack-Foundation-NFV-Report.pdf 08:10:57 I also found the link in OpenStack.org homepage 08:11:11 this is great recognition of our work! 08:11:34 yep ! 08:11:41 page13, a dedicated chapter! 08:11:47 and I will definitely make that f**ing Tshirt this year 08:11:47 yes 08:11:50 for you guys 08:12:02 no, for us 08:12:03 :P 08:12:07 :) 08:12:24 yes, it's great value to do multisite work 08:12:30 that’s a great way to start a day 08:13:01 and mention global and per-site quota management 08:13:02 yes , and we sure have more for them in C and D release 08:13:03 :) 08:13:39 shall we collect in OPNFV for other multisite use cases? 08:14:02 I think usecase 4 and 5 should be a mouthful for us in C and D 08:14:02 after one release, may other teams will raise some requirement on multisite 08:14:17 but we should welcome thoughts if anyone got any 08:14:21 that’as right 08:14:32 but implentation wise I don't think we have the volume for C and D 08:14:36 yes, we need to listen others' 08:14:43 agree 08:15:05 if we have more requirements, may more people join 08:15:20 but for us, limited volume left 08:15:27 yes indeed 08:16:59 action: have be beer :) 08:17:07 hahahah 08:17:12 haha 08:17:13 no 08:17:19 #action have beer 08:17:23 I'll send a mail for inquiry to other teams, but at the same time we mainly focus on current use cases 08:17:34 +1 08:17:53 yes i heard HA team might still have some thoughts on Multisite, let's see what idea could we have 08:18:06 #action send a mail for inquiry to other teams for multisite requirements, but at the same time we mainly focus on current use cases 08:19:32 let's a short talk on the kingbird design 08:19:41 #topic kingbird design 08:19:42 sure. 08:20:00 We have JobDaemon and Jobworker 08:20:24 Can we only have JobWorker or previous Dimitri's engine 08:20:46 any particular reason for it? 08:21:06 that means one process to send out 20 request to 20 regions to query the quota 08:21:17 using eventlets 08:21:31 with threads 08:21:54 or jobdaemon send to multiple jobworker, and each job workers send several requests to regarding regions? 08:22:13 I actually welcome this idea, as it will simplify our design 08:22:34 currently, during my implementation I felt, we have jobdeamon unnecesarry. 08:22:44 which one will have better experience 08:22:45 I have a quotamanager controller 08:23:18 then It can spawn jobworkers for each region 08:23:33 rpc call from jobdeamon and its manager can be removed 08:24:05 where the quotamaneger controller locates, API or jobworker? 08:24:14 API 08:24:37 then it spwans jobworkers 08:24:55 if there is any DB call, it directly access DB without JW 08:25:05 calls related to only DB 08:25:05 jobworkers also in API? 08:25:09 no 08:25:28 only QM will be in API as controllers. 08:25:42 then QM will make a rpc call to JW 08:25:49 so QM will send one msg or multiple msg to JW 08:26:32 yes.. depending on how many regions it has to query. but for that also we need to use eventlet 08:27:03 if cast then no issues, but for call we have to do parallel calls to JWs 08:27:14 what happens what we have multiple controllers? 08:27:34 say one for QM, one for some other sync activity? 08:27:37 each controller is for each usecase. 08:27:41 how about one call to JW, and JW will send multiple requests in parallel 08:28:14 QM => one controller, multisite image replication = another controller 08:28:18 like this 08:28:24 it's stateless restful API, each one is no related to another one "what happens what we have multiple controllers?" 08:28:43 network management => another controller 08:28:58 yes. one will not have effect on others 08:29:04 agree, it's different restful resource, and different controller 08:29:06 Am I making sense? 08:29:22 controllers => solve each usecase 08:29:44 only wonder to know QM will send one message for all regions or per region base 08:29:46 usecases = QM, image replication, network management 08:29:46 got it. I was more thinking that since we can also run in autonomous mode, then controllers will be invoked no via API, but on a scheduled timer 08:30:03 controllers are MVC controllers 08:30:19 oh, ok 08:30:40 it has to be multiple messages to mulitple regions 08:30:45 parallely 08:31:11 or directly send multiple quota rest request directly from API? 08:31:49 from API to JW? 08:32:06 from API directly to other regions 08:32:39 I dnt support, we have to break the design 08:32:46 then It will be only APIs 08:33:44 but from your ideas, API QM has to wait and collect and calculate results from other regions 08:34:43 if send one call rpc to JW, and JW to spawn multiple request eventlet to other regions, then the collection and report will be done in JW single location 08:34:45 quota syncing will be a cast 08:35:40 CAST is async. operation 08:35:43 remaning QM API calls are there. Update/delete/list can be rpc call 08:36:09 then in this case there will be only one JW. 08:37:12 make sense 08:37:25 which one? 08:37:31 the last one 08:38:21 can we have eventlet in controller each spawning JW threads for each region. 08:38:50 so there will be 'n' JWs for 'n' regions 08:39:35 yes, this is my concerns on the comparation of these two ways 08:40:17 " eventlet in controller each spawning JW threads for each region" then we have to put the quota collection function in API 08:40:20 guys, unfortunately I have to leave the meeting now 08:40:32 ok, see you next time 08:40:42 sure.. bye 08:40:42 thanks Dimitri 08:40:45 thanks for the great news! 08:40:56 Have a cup of beer 08:41:00 Multisite is awesome :) 08:41:03 talk to you later sorantis 08:41:09 barrel of beer 08:41:22 ocean :) 08:41:24 multi site of barrels of beer 08:41:31 lol 08:41:37 multiregion beer bashes 08:41:40 you all want my death, huh? :) 08:41:49 hahahs 08:41:52 hahahah 08:42:03 cheers guys! talk soon! 08:42:03 have multiple JWs with you 08:42:06 I will become one 08:42:08 JW for u 08:42:19 So Ashish, could you have a short summary of different idea and comparation, so we can have more discussion and thinking in next meeting? 08:42:31 cheer 08:42:33 sure.. Joe 08:43:00 #action summary of different idea and comparation of quota management implementation 08:43:07 another thing is that we need to arrange for Multisite C release earlier 08:43:29 yes, next time.... Have beer first 08:43:41 hahah... 08:43:48 haha okey i 'll stop typing 08:43:50 ok. thanks attending for today's meeting 08:43:56 see you next time 08:43:58 thanks guys :) 08:44:03 see ya 08:44:07 #endmeeing 08:44:12 sure.. Take care. bye 08:44:19 #endmeeting