01:01:04 <zhiyuan> #startmeeting tricircle 01:01:05 <openstack> Meeting started Wed Nov 1 01:01:04 2017 UTC and is due to finish in 60 minutes. The chair is zhiyuan. Information about MeetBot at http://wiki.debian.org/MeetBot. 01:01:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 01:01:08 <openstack> The meeting name has been set to 'tricircle' 01:01:33 <zhiyuan> #feature progress 01:01:45 <zhiyuan> #topic feature progress 01:02:11 <zhiyuan> let's update our progress of feature development 01:02:57 <joehuang> hello 01:03:03 <zhiyuan> hi joe 01:03:23 <Yipei_> for lbaas, already installed tricircle with nova cell, try integrating lbaas with nova cell. 01:03:52 <Yipei_> improve smoke test to adapt the newly added attribute "enable_tap" 01:05:02 <Yipei_> improve patch https://review.openstack.org/#/c/498407/ and https://review.openstack.org/#/c/511667/ based on the comments 01:05:55 <xuzhuang> for default security group the patch is still under reviewing. for the direction of requests bettween central neutron and local neutron I am thinking the technical scheme 01:08:23 <zhiyuan> for the cell lbaas integration, each lbaas service will connect to one cell, is that correct? 01:09:11 <Yipei_> to zhiyuan, yes 01:09:21 <joehuang> for cells integration, only one LBaaS? 01:09:41 <zhiyuan> I tested and found the patch for default security group worked well, I only have one little comment on the unit test 01:10:59 <joehuang> we need a spec for LBaaS and cells integration, though code development may be just a little 01:12:16 <Yipei_> to joehuang, i will prepare a spec. i just plan to verify the idea we discussed, and then will submit a spec 01:12:27 <joehuang> perfect 01:13:04 <zhiyuan> to xuzhuang, is my reply in the mail clear for you? 01:13:36 <joehuang> may we use openstack maillist to discuss some topic 01:13:39 <RongHui11> hello 01:13:50 <RongHui11> sorry for late 01:14:22 <song> hi, i am song from szzt, is there any small work and not very hurry we can do. 01:15:43 <xuzhuang> i have understanded the global plan, but still have a little problems 01:16:25 <Yipei_> to joehuang, what kind of topic? 01:16:51 <joehuang> I did not see the mail zhiyuan sent to xuzhuang 01:17:55 <zhiyuan> ah, yes, the mail is sent to my personal mail address 01:18:19 <xuzhuang> oh, sorry joe, i sended to zhiyuan and yipei for asking the plan of direction of requests 01:19:42 <zhiyuan> joe's suggestion is that we can discuss such implementation detail in openstack mail-list, with tricircle in the subject 01:20:12 <xuzhuang> ok, I got it 01:20:14 <zhiyuan> to song, what about the improvement of trunk smoke test? 01:20:58 <song> it has worked by our team zhang xiaohan. 01:21:37 <RongHui11> if we continue to work on the smoke test for some other functions. there is some spec for learn ? 01:21:47 <song> trunk somke test is under working. 01:22:09 <RongHui11> or some test case we should test? 01:23:34 <zhiyuan> one feature targeting queens-2 is network deletion reliability 01:24:01 <zhiyuan> and security group deletion depends on it 01:26:45 <zhiyuan> song, is this feature already taken by your team? 01:27:22 <song> my team taken qos and trunk somke test 01:27:33 <song> we have not taken it. 01:28:16 <song> we can do it, if it is not very hard and hurry. 01:29:06 <zhiyuan> queens-2 is from Dec 4 to Dec 8 so it'll be about a month 01:31:09 <zhiyuan> there's already some ideas during the PTG, https://etherpad.openstack.org/p/tricircle-queens-ptg, but we need a spec to discuss the detail 01:31:32 <zhiyuan> see the "Network deletion reliability" section 01:31:38 <song> oh,we can try do it. 01:32:11 <RongHui11> last time we discuss this function and seems not find a good way to solve this problem 01:33:08 <joehuang> sorry, another meeting is waiting for me, I have to leave early. 01:33:15 <RongHui11> bye 01:33:17 <song> bye 01:33:20 <zhiyuan> record the operation state in memory is not enough, so we may need to store the state in DB 01:33:23 <zhiyuan> bye joe 01:33:45 <xuzhuang> bye joe 01:33:54 <Yipei_> bye joe 01:35:07 <zhiyuan> the basic idea is to store a "network-in-delete" state at the beginning of network deletion, so during the deletion, if one "network-get" request comes, we can return 404 01:35:39 <RongHui11> ok 01:36:10 <song> good 01:37:31 <zhiyuan> in the spec, we need to enumerate the cocurrent request scenarios, and see if our solution can handle each 01:39:20 <song> if it do not have the good solution may be queues-2 is hurry for this feature. 01:41:36 <RongHui11> we need to find a good way to solve the conflict 01:42:20 <zhiyuan> yes, it may take some time to reach the solution 01:43:43 <zhiyuan> we can try to finish the spec in queens-2 01:44:03 <song> ok, we try our best to do it. 01:44:26 <song> we will write a doc and send a email.if we have good solution. 01:44:37 <song> to see other people have any other idea. 01:44:47 <song> after that we begin to coding. 01:45:06 <zhiyuan> fine, discuss via the mail list, as Joe suggest 01:45:25 <song> yes 01:45:28 <RongHui11> i think the best way came from experiment 01:46:37 <zhiyuan> yes, the issue for network deletion is easy to reproduce 01:47:00 <zhiyuan> so it's easy for us to test some solutions 01:47:43 <RongHui11> no experiment, if some other conflict come out, it is hard to fix the spec and submit codes 01:50:30 <zhiyuan> that's right 01:50:49 <zhiyuan> other topics? 01:50:56 <song> no 01:51:00 <RongHui11> no for me 01:51:04 <xuzhuang> no for me 01:51:47 <Yipei_> no 01:52:04 <zhiyuan> ok, thanks for attending the meeting 01:52:09 <zhiyuan> #endmeeting