05:35:05 #startmeeting taas 05:35:06 Meeting started Wed Feb 15 05:35:05 2017 UTC and is due to finish in 60 minutes. The chair is soichi. Information about MeetBot at http://wiki.debian.org/MeetBot. 05:35:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 05:35:09 The meeting name has been set to 'taas' 05:35:14 hi 05:35:22 yamamoto: hi 05:35:33 #link https://wiki.openstack.org/wiki/Meetings/taas 05:36:42 i'd like to wait several minutes 05:37:41 hi sorry 05:37:46 i hope anil is availabe today because he added several topics on the Wiki 05:37:50 reedip: hi 05:39:11 soichi, yamamoto I tried to install the following : https://launchpad.net/ubuntu/+source/neutron-taas/0.0.0+git20160926.675af77-0ubuntu1 05:40:22 was it successful? 05:41:20 It was, but after http://paste.openstack.org/show/598935/ 05:41:33 There were a LOT of dependencies which needed to be resolved 05:41:48 installation was successful but it gave a lot of trouble later 05:42:05 so I have marked the test as unsuccesful. 05:42:43 However, I see now that they have launched a new package : https://launchpad.net/ubuntu/+source/neutron-taas/0.0.0+git20161126.094be-0ubuntu1 05:42:50 this is based on the Ocata Master 05:43:14 reedip: thank you for your informatin 05:43:32 but as the package is released before the official release of other packages ( neutron, neutronclient, oslo etc) , it is difficult to test it with other components 05:43:41 because of the unstability of the components 05:44:34 i understood 05:46:47 Updated the wiki for the same :) 05:49:18 let's go on the today's tpoics 05:49:32 #topic Work items to get merged into Neutron Stadium 05:49:34 reedip: have you informed the packager issues you saw? 05:49:42 yamamoto : no 05:50:09 reedip: you will? 05:50:20 But they have mention that the package is from the unstable revision, so I guess that would already be a risk issue 05:51:14 yamamoto : the package has written that its from the current Upstream version ( they have taken the snapshot of the branch from a specific point in the current release , and made a package out of it ) 05:52:07 so , IMHO, it was expected to be a bit unstable. the problem is I installed a base openstack of newton and used this tap package and it failed, and I used it on Mitaka, it failed as well 05:52:26 because this has been taken in between mitaka and newton :| 05:55:56 reedip: if you don't plan to provide a feedback to them, i'm not sure why you tested it in the first place. :-) 05:56:31 yamamoto : hehehe, no I didnt plan, I tested it completely this week 05:56:51 yamamoto : sure, I will ask them to make the package from the official release 05:57:03 reedip: +1 05:57:27 reedip: good idea 05:58:03 i guess there hasn't been many changes from the snapshot though 05:58:14 let's move on 06:01:38 i think it is better to postpone today's topic (work items to get merged into Noutron Stadium) to next IRC meeting becuase anil is not available today. What do you think? 06:02:02 I would not be there next week for the meeting due to PTG :) 06:02:17 reedip: yes 06:02:23 but I can definetly look into the points for stadium there. 06:02:31 yamamoto, soichi, you guys coming? 06:02:40 next IRC will be on the week of 2/27 06:03:15 reedip: yes, i will attend the Atlanta PTG 06:03:35 gr8 soichi :) 06:03:47 reedip: yes 06:04:18 yamamoto : cool. 06:04:24 btw I asked the question on https://answers.launchpad.net/ubuntu/+source/neutron-taas/+question/460600 06:04:54 so hopefully they can answer and we can look forward on the official package for TaaS 06:05:29 reedip: thank you 06:05:39 #topic Open Discussion 06:06:50 do we need role based access control in TaaS ? 06:09:12 i guess it is required if TaaS supports "Legal Intercept". 06:09:37 soichi can you elaborate "Legal Intercept " ? 06:10:08 anil_rao: hi 06:10:19 Hi 06:10:37 reedip: port mirroring by administrator, i think 06:10:41 Sorry for being late to the meeting 06:11:05 anil_rao : no issues, better late than never :) 06:11:36 :) 06:12:07 soichi : hmm, so it means if you want the tap service port to access data of multiple tap flows 06:12:17 of different tenants 06:12:30 and if those tenants actually agree to this, then yes, its possible 06:14:03 Crossing tenant boundaries is not going to be simple, so is there a real need for this. 06:14:36 i suppose an administrator who belongs to a cloud service provider (that is, infra operator) 06:14:50 anil_rao : tenant_boudaries are decided by the policy which would be enforced 06:15:42 anil_rao, soichi: however, if there is a need for tenants to connect their VMs to a cloud admin tap-service, then it can be used. 06:15:58 this issue is not that. Different tenants may have same IP ranges for their subnets and when you being all of that traffic to a common point you will not be able to distinguish anything. 06:16:41 nail_rao: i see 06:16:47 anil_rao : and we are filtering based on the IP and not on the MAC , so yeah that can be an issue 06:17:25 Filtering on MAC is possible in theory but generally not practical because that is very hard to keep track of. Filtering on IP addresses and IP ranges is more commonly used. 06:20:22 The cloud admin can deploy collector VMs in each tenant they want to monitor and have TaaS deliver traffic to those collector VMs. Then from the collector VMs the traffic can be suitably forwarded to any destination of choice. During this second hop the traffic could either be tagged or appropriate tunnel IDs could be used to keep track of different tenants. 06:20:55 I think this problem is more suited to a particular use case. 06:21:29 anil_rao: agree 06:21:32 what do you mean by "tenant"? tenant_id/project_id thing is not necessarily related to network isolation/ip address overlap/etc. 06:22:49 What I was referring to is that two tenants or projects may be using the same IP range (e.g. 192.169.0.0/24). If we placed traffic from these two tenants onto a single tap-service destination port, we won't be able to determine where they originated from. 06:22:53 soichi: reedip: i'm not sure how it maps to rbac. can you explain? 06:23:59 anil_rao: sure, but even a single tenant can use multiple networks with the same ip range. 06:25:05 yamamoto: That is true and in that case I'd recommend the use of separate tap-services. However this situation is not common for a single tenant. Across a tenant is actually very common because common IP ranges are used by everyoen all the time. 06:26:22 anil_rao: what's wrong with separate tap-services for "cross tenant" case? 06:26:22 We have seen many OpenStack deployments where all tenants are given a few default networks with exactly the same IP ranges. :-) 06:27:04 anil_rao : really ??? 06:28:00 reedip: it is more common that you'd think. An admin instantiates tenants from a template and they are just about identical in all respects. 06:28:13 ok 06:28:43 yamamoto: I think separate tap-services for cross tenant case is fine, as long as this is not abused. Now, that would be bad. :-) 06:29:09 yamamoto: I was thinking if there is ever a requirement for a group of tenants to mirror their data to a single destination, but the destination is not exposed to all tenants 06:29:56 One other thing that I have noticed in our experience with traffic monitoring is that the destination will more than likely not be able to handle more than a few source ports. 06:31:03 reedip: so you want rbac for the destination? 06:31:31 If you start taking traffic from multiple tenants to a specifc port you will more than likely create serious conjection. 06:32:37 it seems run out of time 06:32:47 let's continue on the next IRC on the week of 2/27 (next week IRC meeting being canceled because of PTG week) 06:33:10 Sure. I have added a few topics for discusison that we can talk about then. :-) 06:33:29 anil_rao: +1 06:33:46 #endmeeting