05:33:48 <soichi> #startmeeting taas
05:33:49 <openstack> Meeting started Wed Jan 25 05:33:48 2017 UTC and is due to finish in 60 minutes.  The chair is soichi. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:33:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:33:52 <openstack> The meeting name has been set to 'taas'
05:34:03 <soichi> #link: #startmeeting taas
05:34:17 <soichi> #link https://wiki.openstack.org/wiki/Meetings/taas
05:34:36 <soichi> #topic: Review currently open code
05:36:17 <soichi> take a look at the TaaS review Inbox
05:37:11 <soichi> vnyyad: hi
05:37:23 <vnyyad> soichi: hi!
05:37:52 <reedip> vnyyad : hi , we need to step up on the reviews :)
05:37:59 <reedip> if possible :)
05:38:08 <anil_rao> Hi
05:38:12 <reedip> yamamoto: thanks for your review comments
05:38:20 <soichi> anil_rao: hi!
05:38:27 <reedip> hi anil_rao : long time, no c  :)
05:38:39 <vnyyad> anil_rao: hi
05:38:48 <anil_rao> Yes, its been a while ... was caught up in lots of unrelated stuff
05:38:57 <kaz> anil_rao: hi
05:39:12 <anil_rao> should be getting back into TaaS now :-)
05:39:27 <soichi> anil_rao: +1
05:39:48 <soichi> current topic is: Review currently open code
05:40:02 <yamamoto> reedip: np!
05:40:10 <yamamoto> anil_rao: welcome back!
05:40:28 <anil_rao> Thanks.
05:42:25 <soichi> do have any comments for this topic?
05:42:42 <soichi> do have -> do you have
05:43:04 <anil_rao> I have a question for reedip
05:43:19 <reedip> yes ho
05:43:21 <reedip> hi *
05:44:27 <anil_rao> In your patch regarding other tenants /admins being able to delete tap-services and tap-flows, I am interested in hearing what is the expected role of the admin in such cases.
05:44:55 <anil_rao> I.e. can the admin perform such tasks regardless of the tenant.
05:45:13 <anil_rao> thoughts ... anyone?
05:45:51 <reedip> anil_rao : we can modify policy.json to allow only admins to delete all sort of tap flows, but tenant 1 must not delete tap flows of tenant 2
05:46:16 <reedip> that would render the current code of that patch nearly useless, but still  works better than the current condition :)
05:46:59 <anil_rao> W.r.t. intent, I wonder if we should allow the admin to create tap-services and/or add-tap flows?
05:47:18 <anil_rao> We had this discussion long back in the TaaS spec but it never came to a conclusion.
05:47:33 <reedip> anil_rao : and in my observation, should admin be able to delete tap flows ? As tap flows have network data for the tenant, so in terms of security , I would not like admin to have the power to modify tap flows of a tenant
05:48:16 <vnyyad> anil_rao: the rough consensus was that the admin should become a user of the tenant to create any tap objects
05:48:22 <anil_rao> In our original proposal, we had said that a cloud-admin must become a member of a tenant before performing any TaaS operation on that tenant.
05:48:25 <reedip> anil_rao : admins can have the power to create tap-flows and tap-services, for their own uses.
05:48:47 <anil_rao> vnyyad: Yes, that is what I thought.
05:49:58 <vnyyad> reedip: yes for their own networks yes; but tenant networks they should not be able to touch unless they become a user of the tenant
05:50:34 <vnyyad> in other words when a admin for some reason taps a tenant network the tenant shall know of it
05:50:49 <reedip> vnyyad : in that sense, yes
05:51:16 <soichi> vnyyad: it sounds good for me
05:51:24 <reedip> anil_rao : I think then admins cannot create tap flows or services , and thus cannot modify anything for a tenant
05:52:10 <anil_rao> I would have to agree with vnyyad. We must allow the admin to perform such operations but it would be nice if the tenant knew about it.
05:52:10 <reedip> then as yamamoto  proposed in the code review, we can just modify policy.json and resolve it, instead of the current code ( though it solves the problem ) . yamamoto : any thoughts
05:52:53 <reedip> anil_rao : if admin is a user of a tenant, then its tenant-id would be same as that of the tenant of which it is a part.
05:53:00 <yamamoto> i prefer to avoid hardcoding a particular policy.  no opinion about what policy would be reasonable for the default.
05:53:43 <anil_rao> yamamoto: The policy file is the right option.
05:54:25 <anil_rao> We should still have a default though so that there is some policy in the vanilla version.
05:55:02 <vnyyad> anil_rao: +1
05:55:11 <soichi> +1
05:55:58 <reedip> ok, so I would be modifying the policy.json to have a default policy in the Vanilla version
05:56:31 <reedip> but what should be the default policy, should the user owing the tap flow/service only have the authority of those resources?
05:57:15 <anil_rao> I think a good default is to let the admin perform taas operations on a tenant but only if the admin is a member of that tenant.
05:57:35 <anil_rao> Folks who want to prevent admin tapping or silent admin tapping can modify the policy as desired.
05:57:35 <soichi> anil_rao: +1
05:58:38 <soichi> i have a question: who can modify the policy.json?  tenant/admin?
05:59:22 <anil_rao> I am guessing it would be the admin, otherwise the tenant can override the admin.
06:00:12 <reedip> anil_rao : this seems to be a chicken and egg problem
06:00:15 <reedip> :P
06:00:44 <soichi> okay, but i guess it is requirement from a tenant: "who want to prevent admin tapping or silent admin tapping"
06:00:48 <reedip> so the admin controls policy.json and the admin can ignore tenant's request of not wanting tap flows monitored by the admin
06:01:57 <anil_rao> Well, we have to trust the admin in many ways, so if an admin really wants to cheat then this policy file won't be sufficient.
06:02:42 <vnyyad> +1
06:03:12 <soichi> +0.8 :)
06:03:15 <reedip> where is the policy.json for taas ?????
06:03:20 <vnyyad> the policy should be a part of the service agreement between tenant and admin
06:03:30 <reedip> seems my code doesnt have it
06:03:40 <reedip> oh, we dont have it yet
06:03:42 <reedip> sorry
06:04:03 <anil_rao> vnyyad: +1
06:04:23 <soichi> vnyyad: +1
06:04:29 <kaz> +1
06:04:57 <reedip> okay, so admins can control taps of other tenants , thats the final conclusion
06:05:26 <soichi> agree
06:05:32 <anil_rao> reedip: We keep the default as admin can tap any tenant but must be a member of that tenant.
06:05:48 <vnyyad> anil_rao: +1
06:05:52 <soichi> +1
06:05:54 <kaz> +1
06:08:07 <soichi> can we go on next topic?
06:08:10 <anil_rao> reedip: I haven't looked at your patch in detail but in the description I see the mention of adding the check to the 'client'. I am guessing that the policy.json file will apply to the actual TaaS REST apis
06:08:42 <reedip> yamamoto : the path for policy.json would be etc/neutron/policy.d
06:08:50 <reedip> correct me if I am wrong ^^
06:09:18 <reedip> anil_rao : yes, policy.json would apply it for the Rest API and thus handles various client requests as well
06:09:32 <anil_rao> reedip: Thanks.
06:11:26 <reedip> should we move on?
06:11:37 <anil_rao> Sure.
06:11:46 <soichi> #topic: Open Discussion
06:12:17 <soichi> i rearranged the Wiki page
06:12:18 <soichi> i moved items of previous meetings under "Pervious meetings"
06:12:41 <soichi> jurs FYI
06:12:51 <soichi> jurs -> just
06:13:31 <vnyyad> anil_rao: i had added you as a admin for the launchpad for taas can you confirm you have the privileges
06:13:35 <reedip> thanks soichi
06:14:13 <reedip> vnyyad , anil_rao : OpenContrail has support of Port Mirroring, have you guys experimented on it ?
06:14:39 <reedip> I saw the vancouver summit did have something related to it
06:16:01 <vnyyad> reedip: i know they had support, but is there any attempt at developing a taas driver for openContrail?
06:16:04 <reedip> Actually I am proposing an NFV based solution for TaaS and wanted to know what type of Opensource NFV solutions provide port mirroring
06:16:04 <reedip> OpenContrail does, ODL doesnt ( yet )
06:16:31 <reedip> vnyyad : I was attempting to see if it is possible and submit a talk for the Boston summit
06:16:54 <reedip> you guys are also welcome to participate ( last day is 6th  Feb )
06:17:00 <vnyyad> reedip: can you provide the link to their driver if available
06:17:27 <reedip> my talk was to expose taas as a more sensible solution which can be used with other NFV based solutions
06:17:34 <reedip> for port mirroing
06:17:41 <vnyyad> reedip: +1
06:17:56 <soichi> reedip: +1
06:18:07 <reedip> vnyyad : I found it in thier docs ( maybe we have to write a driver ourselves or something :) )
06:19:18 <vnyyad> reedip: thanks, yeah a driver is missing and needs to be developed
06:21:17 <anil_rao> I am not sure what an NFV based solution would be. OpenContrail in an SDN Controller so they can always add taps in the underlying virtual switches.
06:21:43 <anil_rao> I am not aware of OpenContrail working with the TaaS API
06:23:16 <soichi> I hread that Contrail doesn't use OVS. OVS is replaced to vRoutor.
06:24:01 <anil_rao> soichi: Thank is correct. OpenContrail is often used to manage vRouters (from Juniper).
06:24:56 <anil_rao> Thanks --> That
06:26:20 <anil_rao> I think it would be nice to have OpenContrail/vRouter standardize on the TaaS API. Perhaps we can start a dialogue with those folks.
06:26:44 <reedip> :)
06:26:50 <vnyyad> anil_rao: +1
06:26:54 <kaz> +1
06:28:18 <soichi> We asked for Motoki-san to review our Horizon extension (TaaS GUI). He gave many review comments. We will try to modify the code.
06:29:03 <soichi> anil_rao: will you come to PTG in Atlanta?
06:29:16 <reedip> I may be coming
06:29:23 <soichi> +1
06:29:40 <anil_rao> soichi: I noticed in a review comment that the GUI work should be submitteed as an enhancement request to the Horizon Team.
06:30:04 <anil_rao> Is this their recommended way of implementation project specific features?
06:30:05 <reedip> anil_rao, vnyyad : we need to look for being included in the governance. And also our TaaS Spec is not merged
06:30:22 <soichi> anil_rao: okay
06:30:35 <reedip> can you see if anything is required in the TaaS Spec, and merge it if its ok ?
06:30:46 <anil_rao> reedip: Will do?
06:31:02 <reedip> Question mark ??? :)
06:31:25 <soichi> it seems run out of time
06:31:26 <anil_rao> soichi: I wasn't sure from those review comments
06:31:48 <anil_rao> Let's continue next time...
06:31:53 <soichi> sure
06:32:01 <soichi> #endmeeting