05:30:56 <soichi> #startmeeting taas
05:30:57 <openstack> Meeting started Wed Dec  7 05:30:56 2016 UTC and is due to finish in 60 minutes.  The chair is soichi. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:30:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:31:00 <openstack> The meeting name has been set to 'taas'
05:31:17 <reedip> I just republished the OSC patch ...
05:31:19 <soichi> #link https://wiki.openstack.org/wiki/Meetings/taas
05:31:26 <reedip> JFYI
05:31:53 <soichi> reedip: yes
05:32:27 <soichi> #topic spec
05:33:31 <soichi> 1) we should finialize the current spec
05:33:36 <yamamot__> it's a reminder of spec review + some questions from dragonflow folk
05:33:37 <soichi> +1
05:34:00 <reedip> ok
05:34:09 <reedip> Just going through the points
05:34:15 <yamamot__> first, please review the spec.
05:34:17 <yamamot__> #link https://review.openstack.org/#/c/256210/
05:34:53 <yamamot__> and assuming the spec is ok, now we have a possible extension to the spec
05:35:07 <yamamot__> ie. "position" parameter
05:35:23 <reedip> yamamot__ : the spec looks fine by me , but we need some neutron cores as well to review it
05:35:26 <yamamot__> and we need some clarification about tap on tap
05:35:57 <yamamot__> reedip: i don't see why. we are not neutron.
05:36:16 <reedip> yamamot__ then whats stopping us from merging it :)
05:36:29 <yamamot__> i don't know.
05:36:48 <yamamot__> it just needs another +2 i guess
05:37:01 <reedip> you can give it +2 , right ?
05:37:21 <vnyyad> i am reviewing it will push it thru today by my evening
05:37:22 <reedip> unless you are the author ( I forgot )
05:37:30 <yamamot__> vnyyad: thank you
05:37:35 <reedip> vnyyad : great to see you here :)
05:37:49 <soichi> vnyyad: +1
05:37:56 <vnyyad> thanks :)
05:38:15 <vnyyad> great to see you all too
05:38:42 <yamamot__> vnyyad and i are authors of the spec, anil's +2 would be ideal.
05:38:51 <yamamot__> is he busy these days?
05:38:58 <vnyyad> yes he was
05:39:21 <vnyyad> i will mail him regarding this now and see what he has to ay
05:39:25 <vnyyad> *say
05:40:26 <yamamot__> thank you
05:40:56 <yamamot__> any of you need explanation about "position" parameter?
05:41:26 <soichi> yamamot__: yes, could you explain a little bit about "position" parameter?
05:41:33 <yamamot__> it was in an earlier version of the spec but reverted when we decided to concentrate to the basic functionality
05:41:47 <yamamot__> and now dragonflow folks want it.
05:42:06 <yamamot__> midonet wants it too.
05:42:19 <yamamot__> it's an attribute for tap-flow
05:42:39 <yamamot__> it controls traffic is tapped before or after SG processing
05:42:56 <soichi> i see
05:43:23 <vnyyad> ok i remember
05:43:42 <yamamot__> i guess the alternative position is almost impossible to implement for the current reference implementation, where SG is implemented as a separate bridge.
05:44:03 <yamamot__> so it's at this point for the benefit for vendors.
05:45:18 <soichi> i understood
05:45:19 <yamamot__> i guess i (or probably dragonflow folk) can submit an extension spec once the current spec is merged.
05:45:27 <vnyyad> ok... does this need to a runtime thing so something that can be configured while setting up tas
05:46:06 <vnyyad> if runtime we need the field
05:46:32 <yamamot__> i'm not sure what you mean
05:47:35 <vnyyad> i mean if we want to choose position differently for each tap flow setup then its more on the run time and need a parameterr
05:48:16 <vnyyad> but if we say as a config all tap tapping is done either before the sc or after the sc then it can be defined in the configuration file
05:48:44 <yamamot__> which configuration file?
05:49:25 <vnyyad> taas config
05:49:42 <yamamot__> you mean plugin config?
05:49:56 <yamamot__> ie. neutron server config
05:50:21 <vnyyad> yeah plugin config ... would that be possible or even meaning full
05:51:23 <yamamot__> it's possible but i don't see any benefit.  the plugin still need to tell agents which position should be used.
05:51:26 <reedip> interesting , and considering that most users would want all their taps to be placed in a single location ( before or after SG ) but the choice of position would vary between the users
05:51:51 <yamamot__> and it's inconsistent among deployment from POV of api users
05:52:07 <soichi> i guess it depends on the position is configured or specifed by OpenStack operator or user (tenant)
05:52:08 <vnyyad> yeah... ok
05:52:26 <vnyyad> i agree
05:53:12 <yamamot__> next topic is "tap on tap"
05:53:37 <yamamot__> it's also raised by dragonflow folks
05:53:58 <yamamot__> #link https://review.openstack.org/#/c/396307/  dragonflow taas spec
05:55:01 <yamamot__> a question is, what should happen if we configure mirroring from port-A to port-B, and another mirroring from port-B to port-C
05:55:26 <yamamot__> port-C should see which traffic?
05:56:04 <yamamot__> i listed a few choices on the wiki
05:56:11 <soichi> i think b) mirror all traffic on the port, including mirrored traffic
05:56:45 <soichi> in case "ingree" or "both" is specied on port-B
05:56:56 <yamamot__> i thought b) too, it's the reason why i implemented it in midonet that way.
05:57:03 <kaz> i think so, traffic on the port-A and port-B will be seen.
05:57:16 <yamamot__> but i guess for some implementations it's difficult to avoid loop
05:57:43 <yamamot__> eg. A and B tap each other
05:58:05 <kaz> i see
05:58:22 <yamamot__> so "a) prevent it at plugin level?" might be the safest bet
05:58:31 <oanson> Maybe loop avoidance in the northbound? Throw an error when the last edge in the loop is added?
05:59:13 <yamamot__> oanson: good point
05:59:53 <yamamot__> for those who don't know: oanson is a dragonflow folk.
06:00:13 <vnyyad> oanson: +1
06:00:18 <soichi> +1
06:00:27 <yamamot__> oanson: you mean at plugin level right?
06:00:41 <oanson> Yes. We're working on implementing the API in Dragonflow, and this is a corner-case we were wondering how to solve
06:00:46 <oanson> yamamot__, yes
06:02:33 <yamamot__> i wonder how complex a loop detection will be.
06:03:01 <yamamot__> if we can use CTEs it's easy, but i guess we can't.
06:03:44 <oanson> What about cycle detection algorithms in graphs?
06:04:13 <oanson> It's O(V+E), where V is services, and E is flows (vertices and edges in the original)
06:05:15 <yamamot__> yes. my concern is how to apply it to our implementation in a race-free manner.
06:06:21 <yamamot__> any volunteer to design/implement the loop detection?
06:07:00 <yamamot__> and if we go the route, we need to do something for the reference implementation i guess.
06:07:50 <reedip> I am still not clear , its new for me :)
06:08:05 <yamamot__> which part is not clear?
06:12:15 <yamamot__> as it's merely a safety rope anyway, i guess the detection doesn't need to be strict.  eg. we can terminate if the chain is longer than X.
06:13:17 <yamamot__> is this the last topic for today?
06:13:24 <soichi> i think the loop detection is an interesting topic, but we need more time to think it deeply.
06:13:51 <yamamot__> soichi: +1 let's make it a homework for this week
06:14:01 <vnyyad> soichi: +1
06:14:01 <soichi> okay
06:14:39 <yamamot__> #action all think about loop detection
06:16:16 <soichi> Kaz requested for Motoki-san to review TaaS GUI
06:16:27 <yamamot__> can you change the topic?
06:16:37 <soichi> #topic TaaS GUI
06:16:44 <soichi> Kaz requested for Motoki-san to review TaaS GUI
06:16:49 <soichi> JFYI
06:16:52 <kaz> i sent a mail to Motoki-san and  i asked him to be a reviewer of my TaaS dashboard patch.
06:17:20 <yamamot__> thank you
06:17:35 <soichi> #topic Open Discusstion
06:17:53 <yamamot__> i created newton branch
06:18:13 <soichi> +1, thank you
06:18:15 <vnyyad> yamamot__: thanks
06:18:26 <kaz> +1
06:18:47 <reedip> +1
06:19:04 <yamamot__> a lesson here is the fact taas is actually used by other projects. :-)
06:19:18 <soichi> great!!
06:19:36 <vnyyad> awesome!!!
06:19:52 <reedip> We need to get the Spec approved and move this to governance :D ( just my thoughts )
06:20:01 <yamamot__> a reminder for reviewers: there are a few patches for the branch already.
06:20:14 <yamamot__> #link https://review.openstack.org/#/q/status:open+project:openstack/tap-as-a-service+branch:stable/newton newton reviews
06:20:48 <soichi> reedip: sure
06:21:38 <soichi> yamamot__: i will check them
06:21:51 <reedip> I have a question
06:22:00 <reedip> thats related to deployment and packaging of TaaS
06:22:22 <reedip> is there a document which highlights how TaaS should be deployed in a test env ?
06:22:43 <reedip> And is there any current plan for packaging it ( as an RPM ) for test clouds?
06:23:01 <yamamot__> i thought there is ubuntu package
06:23:12 <yamamot__> i don't know which version is it though
06:23:15 <reedip> really ????
06:24:00 <reedip> I didnt know that
06:24:07 <vnyyad> hmmm did not know either
06:24:15 <yamamot__> #link https://launchpad.net/ubuntu/yakkety/+package/python-neutron-taas
06:24:49 <reedip> So we can use it to deploy taas ??
06:25:06 <yamamot__> i guess so. you can try. :-)
06:25:19 <vnyyad> oh yeah it does exist :)
06:25:49 <reedip> Ok, let me try it then :D
06:26:08 <yamamot__> they are keen to package every software i guess :-)
06:26:28 <reedip> It seems so :)
06:26:37 <yamamot__> #action reedip try ubuntu package
06:26:44 <reedip> Good that they are, atleast we can make something with it
06:26:59 <reedip> yamamot__ I am trying to create a document which highlights TaaS
06:27:09 <reedip> I mean how to use it, deploy it , et al
06:27:16 <soichi> reedip* +1
06:27:32 <reedip> I think it can be used as a reference document for everyone ( new developers/users etc ) so that they can test it out
06:27:50 <reedip> and we can keep this doc in (1) Repo or in (2) Wiki
06:28:27 <vnyyad> reedip: +1
06:28:38 <soichi> both (1) and (2)  :)
06:29:00 <reedip> soichi : hehe . Ok I will :)
06:29:11 <kaz> +1
06:29:30 <yamamot__> i prefer (1) as i prefer doc and code live together.
06:29:51 <yamamot__> 1 min left
06:29:58 <reedip> we can link the doc with the wiki
06:30:10 <reedip> i am done with this point , thanks guys
06:30:17 <yamamot__> thank you
06:30:22 <soichi> it looks we run out of time
06:30:29 <reedip> #action reedip to create a doc
06:30:39 <soichi> see you next week
06:30:47 <yamamot__> bye
06:30:48 <soichi> #endmeeting