13:03:45 #startmeeting tricircle 13:03:46 Meeting started Wed Dec 9 13:03:45 2015 UTC and is due to finish in 60 minutes. The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:03:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:03:50 The meeting name has been set to 'tricircle' 13:04:07 let's start the weekly meeting 13:04:12 ok 13:04:13 #info zhipeng 13:04:14 #rollcall 13:04:19 #topic rollcall 13:04:23 #info joehuang 13:04:26 #info zhipeng 13:04:31 #info zhiyuan 13:04:57 #topic todo list 13:05:14 #info https://etherpad.openstack.org/p/TricircleToDo 13:06:07 let's have a look on the todo list 13:07:08 the table for routing information needs to update 13:07:33 as the top layer may manage a lot of bottom openstack instances 13:07:48 the routing table will have millions of records 13:08:01 it'll grow into very very big 13:08:38 yes, I have added "resource_type" and “project_id” fields to the routing table, will submit this along with the Neutron plugin patch 13:08:41 therefore, we need to split the table into several smaller tables, like vm routing table, volume routing table, port routing table.. 13:08:46 great 13:09:25 #action divide the routing table to smaller ones, specific to resource type and project 13:09:39 bp for stateless architecture has been registered. 13:09:39 https://blueprints.launchpad.net/tricircle/+spec/implement-stateless 13:09:52 hi zhiyuan, could you have some words about your progress in phase 1 13:10:19 #info https://blueprints.launchpad.net/tricircle/+spec/implement-stateless 13:10:37 joehuang is it possible for bottom openstacks to handle the table, and top just querry it every time an operation on certain bottom is required ? 13:11:02 i think if you split the table, they could still get very big 13:11:15 and instead of one big table, you got three big tables 13:11:20 routing table is just to be used for forwarding purpose, it's necessary 13:11:49 no routing table, each time you have to broadcast the vm operation or volume operation 13:12:17 for example, reboot vm 13:12:31 ok, (1) the init patch for stateless architecture and patch for new tables have been merged. (2) bp for stateless architecture has been registered. (3) now I am working on the Neutron plugin 13:12:43 if we do not store the whole table in top, but only references, and keep the table at the bottom 13:12:47 would that work? 13:12:59 the request has to be broadcast to all bottom openstack because the top doesn;t know where it is 13:13:13 that's the idea 13:14:07 zhiyuan_ the neutron plugin is for PoC ? 13:14:22 joehuang ok 13:14:37 zhiyuan has done great job for these patches 13:14:46 yep 13:15:27 from my side, the nova-apigw, and cinder-apigw has been submitted and get merged today 13:15:37 and the XJob is WIP 13:16:25 zhiyuan_ we need to register a rfe for networking-tricircle, right ? 13:16:26 IPAM needs to be done on top layer, so we are going to keep Neutron service to utilize the original IPAM process, but write our own core plugin 13:17:04 so we can do extra operation like building routing table in our own core plugin 13:17:13 don't know the current requirements to register a plugin in neutron 13:17:28 i've sent out emails to ask about this 13:17:35 but no reply yet 13:17:41 on the right procedure 13:17:54 ok, zhipeng please investigate how to do that 13:18:11 okey 13:18:16 #action how to add a new plugin to neutron 13:18:39 what we did in the master branch is that we put the plugin in our own repos, and write our own DevStack plugin to install the plugin to Neutron 13:18:53 Neutron allows us to change core plugin 13:19:16 currently I follow this way 13:19:27 is it possible for us to have a work basis for phase one by the end of next week 13:20:10 I think the way we use in master branch works recently, especially for experiment branch 13:20:29 I think my patch for core plugin can be submitted by the end of this week, so it's possible to finish phase 1 by the end of next week 13:21:23 great, let's try to finish a solid basis of phase 1 by the end of next week 13:21:46 okey 13:21:55 ok, we can check the progress in the next meeting 13:22:15 btw I added some info about how kubenetes is doing federation now 13:22:39 quite similar to our stateless approach 13:22:40 in the design doc ? 13:22:47 yes at the end of it 13:23:02 I think it would be the similar idea to build a large system 13:23:03 it is still wip for k8s 13:23:20 yep 13:23:29 how about tacker 13:23:55 I think we can discuss with tacker that they can leverage the tricircle for multi-vim 13:24:15 yes i think that is a great collaboration point 13:24:25 i will wait for their reply 13:24:43 at least for the logical concept the tacker can see should includes AZ and Region 13:25:05 yes, and we need to persuade them to utilize tricircle more 13:25:07 the VNF needs to be aware of AZ 13:25:22 where the application is deployed 13:25:23 instead of build similar solutions 13:25:26 yes 13:27:45 anyways check out the k8s solution see anything would benefit us :) 13:29:50 can you input any information 13:30:20 i added a new section at the end of the design doc 13:30:21 the chat exit suddenly 13:30:54 okey no problem, i didn't say much :) 13:30:56 ok, let's conclude today's meeting 13:31:14 okey 13:31:22 ok 13:31:23 #endmeeting 13:31:36 it doesn't work now 13:31:48 since your irc handle has been changed 13:32:03 you need to be joehuang to end the meeting 13:32:11 ok 13:32:15 bye 13:33:29 #endmeeting