06:30:11 #startmeeting taas 06:30:12 Meeting started Wed Nov 18 06:30:11 2015 UTC and is due to finish in 60 minutes. The chair is vnyyad. Information about MeetBot at http://wiki.debian.org/MeetBot. 06:30:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 06:30:15 The meeting name has been set to 'taas' 06:30:17 hi 06:30:20 Hi 06:30:23 hi 06:30:31 Hello 06:30:50 good morning/noon/afternoon/night :) 06:30:55 o/ 06:31:51 shall we get into the agenda 06:32:22 thanks soichi for proposing the items for this weeks agenda 06:32:33 #link https://wiki.openstack.org/wiki/Meetings/taas Agenda 06:33:48 i got several important comments from Anil. 06:34:43 i guess anil is not in the meeting today but as he replied his commtnst to all of us we can discuss them 06:35:07 soichi: kaz: are you sure that "A mirrored traffic double back to br_int" is a real disadvantage? 06:35:49 yes, in terms of efficency. 06:35:54 as all userland bridges connected by patch ports are handled by a single datapath anyway... 06:36:24 soichi: do you have numbers? 06:37:41 excuse me, but what do you mean "numbers"? number of datapath? 06:37:58 soichi : performance numbers i suppose 06:38:22 yes, benchmark results 06:38:28 currently, we does not have. 06:39:23 We are under planning to mesure. 06:39:24 ok. my guess is there isn't much difference performance-wise. 06:40:17 I thnk it must have complex flow entries. 06:41:44 kaz: userland flows, i agree. i suspect no much difference in kernel flows though. 06:43:34 Sorry, what is "kernel flows"? 06:43:56 kaz: odp flows (vs openflow flows) 06:44:32 Hi 06:45:14 kaz: are you familiar with ovs implementation? 06:45:51 I can't answer right now. 06:48:27 anil has explained the reasons behind the current design in his mail yesterday 06:48:31 Hello, I saw in Media: OperationsFromGUI_20151116-01.pdf that the TAP CLIs are supported. But I couldnt find any option in the Neutron Client 06:49:50 reedip: currently taas uses a dedicated "taas" command. 06:50:09 vnyyad: yes, i am trying to understand the backgroud. 06:50:23 reedip: Neutron client support for taas is proposed by soichi 06:51:27 should we have a mail list to discuss these items 06:51:51 taas - is just port monitoring or helps in vm ha? 06:52:00 vnyyad: what's wrong with openstack-dev? 06:53:16 yamamoto: we can use it, i guess we add [taas] to the subject 06:53:33 trinaths: just monitoring. it might be able to be used for some kind of HA but i have no idea. 06:53:36 vnyyad: sure 06:53:50 yamamoto, vnyyad: It would be good if the following agendas are discussed on emails, so that everyone in loop knows whats happening. And I agree with yamamoto that the Openstack devlist with [taas] can be used 06:54:23 reedipt: sure, that will be done from now on 06:54:30 shouldn't it be [neutron][taas]? 06:54:43 +1 [neutron][taas] 06:54:47 yeah, [neutron][taas] sounds better 06:54:47 yamamoto: okay. what more can be done using this monitoring? 06:57:34 +1 06:57:37 +1 06:58:03 trinaths: currently it is for mirroring the traffic from a particular port to another port, what you do with the mirrored traffic is not covered under taas right now 06:59:48 +1 [neutron][taas] it will be 07:00:20 kaz: soichi: are you going to submit horizon patch? 07:03:18 #info we'll use [neutron][taas] on openstack-dev 07:03:20 No, it is just a first prototype. Before submit to horizon, we would like to share in TaaS project. 07:03:46 vnyyad: can you be more clear on "particular port to another port" * 07:04:29 trinaths: from one neutron port of another neutron port (which is call the tap service port) 07:05:17 trinaths: both ports belong to the same tenant 07:05:34 soichi: thanks for the work on horizon support for TaaS 07:05:53 +1 07:05:59 dedery: +1 07:06:06 dedery: this maybe the case, that admin wants to mirror tenant traffic 07:06:34 vnyyad dedery: confused 07:08:15 irenab: In the current implementation the admin has to create a user under the tenant to mirror flow 07:08:16 irenab: i'm aware of the use-case (especially lawful intercept) from what i read in the bp there was quite a discussion about this 07:09:01 irenab: not sure if the discussion reached any actionable conclusion 07:09:21 irenab: this was done to keep tenant in the loop that their traffic is being monitored by the admin, mainly for privacy 07:09:57 dedery: yes it was discussed at length during the spec reviews 07:13:07 trinaths: Please refer to https://github.com/openstack/tap-as-a-service and the spec at https://review.openstack.org/#/c/96149/8/specs/juno/tap-as-a-service.rst 07:13:54 how about finishing agenda items before having random discussions? 07:14:07 yamamoto: +1 07:14:10 dedery: fair enough 07:14:11 yes sure 07:14:13 :) 07:14:14 vnyyad: thank you. will go through them 07:14:28 vnyyad: can you use #topic to avoid sidetracking? 07:14:48 yamamoto: i will 07:15:24 #topic isolation of production and mirrored traffics 07:16:38 We proposed a dedicated tunnel to carrying mirrored traffic. 07:17:32 soichi: can you provide the link ? 07:17:49 #link https://wiki.openstack.org/w/images/7/78/TrafficIsolation_20151116-01.pdf 07:18:14 thank you 07:18:35 I didn't mentioned in the document, 07:18:59 soichi: this might be helpful if there is a separate physical network to carry the mirrored traffic 07:19:22 definitely 07:19:27 but if uses the same underlying physical network what might be the advantage 07:20:24 The design was not to introduce more tunnels then already there 07:20:45 Although it depends on the physical configuration of a host, we want to map trafiics to different pysical NIC 07:22:12 soichi: in cases of having a different physical networks i see a good use of the proposed design, one network for production traffic and another for mirrored and admin and other traffic 07:22:33 I may be easy to control QoS. 07:24:31 any thoughts on this from others 07:25:54 i wonder how much it complicates the code 07:26:27 we have 5 mins in the meeting, i propose that we bring this up for discussion in the next meeting too along with discussing this on the mailing list 07:26:54 we would like to share the source code we have implemented. 07:27:09 soichi: great. 07:27:24 vnyyad: +1 07:27:24 soichi: that would be good 07:28:28 let's move on quickly 07:28:33 soichi: +1 07:28:37 On the Dashboard support for TaaS, The effort is really appreciated and thanks for that 07:28:54 tahnks 07:29:00 #link https://wiki.openstack.org/w/images/2/2e/OperationsFromGUI_20151116-01.pdf 07:29:25 I found only Create and Delete options, is an Update option viable? 07:29:25 Anil in his mail has some good suggestions on this 07:31:07 reedip there is not option for update yet in the TaaS API, we currently support create and delete for Tap Service and Tap Flow 07:31:26 ok 07:31:33 reedip: i guess it isn't too important as only updatable fields akkkre name and description 07:31:47 i have to end the meeting now, but will add the items remaining to the next meeting agenda 07:31:52 yamamoto: I was also thinking in the similar lines 07:32:18 any other business 07:32:43 vnyyad: sure. and/or discuss on ML. 07:32:53 ok then 07:32:58 thank you 07:33:01 Bye everybody 07:33:03 Please share Anil's comments on the ML 07:33:08 thank you 07:33:10 bye 07:33:10 thank you all 07:33:11 bye 07:33:12 that would allow everyone to come in sync 07:33:18 reedip: we will 07:33:23 bye 07:33:25 +1 , tc :) 07:33:31 #endmeeting