05:34:02 <anil_rao> #startmeeting taas
05:34:03 <openstack> Meeting started Wed Mar  8 05:34:02 2017 UTC and is due to finish in 60 minutes.  The chair is anil_rao. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:34:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:34:06 <openstack> The meeting name has been set to 'taas'
05:37:50 <anil_rao> Hello kaz
05:37:58 <vnyyad> Hi
05:38:19 <anil_rao> Hi Vinay. Looks like its just Kaz, you and I today
05:38:21 <kaz> anil_rao, vnyyad: hi
05:39:29 <anil_rao> I would like to discuss a few technical things today.
05:39:32 <vnyyad> anil_rao, Kaz: we can start with error handling that anil wanted to discuss last week
05:39:56 <anil_rao> sure vnyyad
05:40:29 <anil_rao> I listed out the following scenarios that we need to handle
05:40:46 <anil_rao> port deletion -- source side and destination side
05:41:06 <anil_rao> source and destination side port (VM) migration from one host to another
05:41:49 <anil_rao> host shutdown/restart for source port and destination port
05:42:05 <reedip_> hi
05:42:19 <anil_rao> reedip_: hi
05:42:35 <reedip_> anil_rao : also  one more scenario
05:43:03 <reedip_> anil_rao : Have 3 tap flows with a tap_service, transfer data on the 3 flows. Delete one flow and see what happens
05:43:05 <anil_rao> And finally, failure to complete tap service and tap flow calls
05:43:50 <reedip_> anil_rao: as per the experiment done my associate, he said that the other 2 running tap-flows also stopped sending data
05:43:50 <anil_rao> reedp_: Not sure what you are referring to. Do you see a problem with this specific configuration.
05:44:37 <anil_rao> reedip_: I haven't seen this myself. I'll test it out tomorrow from the offic and let you know.
05:45:03 <anil_rao> we are currently discussing the error handling cases for TaaS. Let us cover this topic since we have skipped it for the past two meetings.
05:45:34 <anil_rao> Are there any other scenarios that we should consider out of the ones I just listed.
05:46:52 <vnyyad> anil_rao: we can start with these, i am sure we will hit upon more as we use taas more
05:47:07 <anil_rao> vnyyad: Sounds good.
05:47:38 <anil_rao> I would also like for us to use the status variable introduced by kaz to report errors back to the caller.
05:48:52 <kaz> +1
05:49:20 <anil_rao> One question: today we cannot support creation of a tap-service or tap-flows for ports that do not have a host binding (i.e. they are not in use).
05:50:00 <anil_rao> If we are going to stick with this policy, the the deletion of a source or destination port should result in the deletion of the tap-flow or tap-service itself.
05:50:15 <anil_rao> How to you all feel about this?
05:50:53 <anil_rao> That same would also hold if just the host binding for a port got removed.
05:51:03 <vnyyad> anil_rao: this would be limiting
05:52:00 <anil_rao> vnyyad: Agreed. But retaining the tap-service and/or tap-flow for ports that don't have a host binding will need more support at the plugin and agent level.
05:52:15 <vnyyad> we need some other way to identify the TaaS agents to the plugin
05:52:32 <vnyyad> some kind of registrations with the plugin when the agents come online
05:52:57 <anil_rao> vnyyad: Yes.
05:54:18 <anil_rao> I think we will also need entries in the TaaS DB about whether a port is instantiated on a host or not.
05:54:35 <reedip_> anil_rao , vnyyad : sorry, I have to leave . I will check the meeting logs and discuss offline, if that is ok ?? :)
05:54:58 <anil_rao> reedip_: Sure. I'll email all of you with the experiment result you asked for.
05:55:37 <vnyyad> anil_rao: yes
05:56:19 <anil_rao> vnyyad: The more I think about this, we should perhaps abandon the learning capability we have today and just rely on controlling everything from the centralized plugin.
05:56:41 <anil_rao> Not sure how well this would scale but it would be a lot simpler, if we are to support what we are discussing today.
05:56:49 <vnyyad> anil_rao: the idea of using  the port binnding was to be able to send unicasts directed at agents to handle the action of taas
05:57:34 <vnyyad> but without host binding we can use the port-id to identify the port and broadcast the message
05:58:42 <vnyyad> so the agent which has the port on its host will only act; rite now i guess the code waits of a message and acts if the message has the hosts-is as its own, hence avoiding the search for ports on that host
05:58:57 <vnyyad> is my inference correct here?
05:59:16 <anil_rao> One other way would be to continue to do the unicast but run everything out of the plugin (SDN model). the plugin knows about the host binding. If there is no host binding no request goes out to any agent.
06:00:06 <vnyyad> anil_rao: i personally like this approach, the SDN based one
06:00:46 <anil_rao> I am playing around with the source code ... let me mock up a working prototype and then you and the others can make improvements as necessary.
06:01:01 <vnyyad> ok
06:01:08 <anil_rao> My main concern is the following:
06:01:19 <vnyyad> you mean the SDN approach?
06:02:09 <anil_rao> No, not the SDN approach. Just something we should support which is prompting me to go along with the SDN approach. Let me explain.
06:02:23 <vnyyad> ha ok
06:02:32 <anil_rao> If a soure port is deleted, we can delete the assocaited tap-flow.
06:02:58 <anil_rao> If a destination port is deleted, we can delete the tap-service, which will automatically also remove all assocaited tap-flows.
06:03:26 <anil_rao> If a source port's host binding is gone, we place that tap-flow in a non-active state.
06:03:46 <anil_rao> If a destination port's host binding is gone, we place the tap-service in a non-active state.
06:04:29 <anil_rao> For the last case, we should also pause all tap-flow traffic otherwise we will be doing mirroring for no good reason. Or in other words all tap-flows also go non-active, if the tap-service is non-active.
06:04:45 <vnyyad> anil_rao: +1
06:05:00 <anil_rao> looks like we are in sync. :-)
06:05:27 <kaz> +1
06:05:53 <vnyyad> also should be handle migration as a sequence of delete and creates
06:06:20 <anil_rao> Exactly.
06:06:47 <anil_rao> I'll get back in a couple of weeks with something that is working. We can refine the solution from there.
06:07:41 <vnyyad> anil_rao: thanks, shoot a mail for any sharing of f lead :)
06:07:59 <vnyyad> load
06:08:05 <anil_rao> Sure. :-)
06:08:18 <anil_rao> One other topic I wanted to discuss, if that is okay.
06:09:09 <vnyyad> go on
06:09:27 <kaz> ok
06:09:42 <anil_rao> When an admin is creating a tap-service, as opposed to a tenant, we should allow the destination port to reside in a different (system) tenant.
06:10:11 <anil_rao> Otherwise, the admin would have to instantiate a monitoring VM inside the tenant that is being monitored, which looks odd.
06:11:25 <anil_rao> What do you guys think?
06:11:42 <vnyyad> anil_rao: this should be ok as long gas the admin is a user in both the tenants
06:11:56 <anil_rao> Yes.
06:12:12 <vnyyad> this way we can be sure to address the privacy question that we dealt with in the early stages
06:13:07 <vnyyad> this make sense, we should probably do this, as this is also the need in many usecase, one being in telco
06:13:16 <anil_rao> vnyyad: I a recent IRC meeting (TaaS) we had discussed a few different scenarios that would be controlled via a policy mechanism that the admin sets up.
06:13:58 <anil_rao> The default would be for admin to be a member of the user tenant but we could have a differnt case where the admin is not a member (hidden monitoring by tenant).
06:14:01 <vnyyad> anil_rao: ok
06:14:47 <anil_rao> We recently had a customer ask for a very special case (I am not convinced we need to support it).
06:15:25 <anil_rao> The entity initiating traffic monitoring is neither the user tenant nor the admin.
06:15:46 <anil_rao> The ask was for "lawful intercept" that should not be undone by the cloud-admin.
06:16:42 <vnyyad> anil_rao: yes that is a valid use case... but to do it without the knowledge of tenant is not good i guess
06:17:11 <vnyyad> in most cases the tenant knows that there is a lawful intercept question
06:17:35 <anil_rao> Sounds like some countries want to do it without the tenant being aware that they are being monitored. :-)
06:17:41 <vnyyad> hahaha
06:18:20 <anil_rao> I think we can leave it for those folks to implement a special policy like this if they really need it.
06:18:24 <vnyyad> sure then it should be handled as a policy of the cloud admin
06:18:33 <vnyyad> anil_rao: +1
06:19:08 <anil_rao> I am done with the 2 topics I had.
06:21:06 <anil_rao> Any new about the TaaS package that Ubuntu apparently produced a short while back?
06:21:24 <anil_rao> Reedip was mentioning it in the last IRC meeting.
06:27:12 <vnyyad> vnyyad: i guess none of us anything more to discuss
06:27:30 <anil_rao> We can end a little early. :-)
06:27:51 <vnyyad> +1
06:27:57 <kaz> yes
06:28:06 <anil_rao> #endmeeting