06:29:54 <anil_rao> #startmeeting taas
06:29:55 <openstack> Meeting started Wed Apr  6 06:29:54 2016 UTC and is due to finish in 60 minutes.  The chair is anil_rao. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:29:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:29:58 <openstack> The meeting name has been set to 'taas'
06:30:05 <yamamot__> hi
06:30:08 <anil_rao> Hello
06:30:10 <soichi> hi
06:30:13 <kaz> hello
06:30:36 <anil_rao> Great, let's get started.
06:31:04 <anil_rao> #topic Summit planning schedule finalization , and what are our AI for the summit
06:31:49 <anil_rao> Do folks feel we need a separate topic for TaaS
06:31:50 <soichi> #link: https://etherpad.openstack.org/p/newton-neutron-summit-ideas
06:32:09 <soichi> what do you say to add TaaS (*aaS) as a topic?
06:32:27 <anil_rao> I am for it. :-)
06:33:05 <soichi> okay, thank you.
06:33:31 <soichi> i think we need to join discussion about ovs agent refactoring (e.g. soft restarting)
06:33:37 <soichi> issue: when ovs agent restarted, taas flows (and flows without cookie) will be removed
06:33:51 <anil_rao> soichi: Agree. I'll add some entries in there
06:34:08 <soichi> yes, please
06:34:39 <anil_rao> Let's move to the next item
06:35:00 <anil_rao> #topic TaaS Dashboard discussion
06:35:24 <soichi> i hope the dashboard works fine on your site
06:35:35 <anil_rao> soichi,kaz: I will be installing theTaaS dashboard tomorrow.
06:35:53 <anil_rao> I wanted to first ensure that the neutron client option was working correctly.
06:36:03 <soichi> i see
06:36:20 <soichi> now we have only 2 weeks or so until summit
06:36:26 <soichi> so, i'm planing to prepare a back up plan
06:36:39 <soichi> that is, making a demo video to show how to create a tap-service and a tap-flow from dashboard
06:37:08 <anil_rao> soichi: I have most of the backend side working already. After I hook up the Dashboard the plan is to record everything on a video.
06:37:28 <anil_rao> We will be using two experiments -- 1) data-analytics and 2) security (IDS)
06:37:47 <anil_rao> The plan it to drive things via the GUI
06:38:17 <soichi> it dounds fine
06:38:26 <soichi> dounds -> sounds
06:38:39 <anil_rao> soichi: I might have some questions for Kaz and you if I run into a problem.
06:39:08 <soichi> yes, of course
06:39:45 <anil_rao> I think the Dashboard will be a big step forward compared to last year's demo. :)
06:39:59 <soichi> thank you
06:40:20 <anil_rao> soichi, kaz: Anything else you wanted to add/update on the Dashboard?
06:40:47 <soichi> we don't have
06:41:06 <anil_rao> Here is one if you don't mind.
06:41:13 <soichi> yes
06:41:54 <anil_rao> My current DevStack already has the new version of Horizon network topology. I am guessing that after I being in the Kilo commit I should be back to the older format
06:41:59 <anil_rao> Is that correct?
06:43:19 <soichi> yes, you need to use the commit written in the instcution guide Kaz had sent to you
06:43:39 <anil_rao> Thanks for confirming. Sounds good.
06:44:20 <anil_rao> #topic Update on TaaS traffic testing
06:44:47 <anil_rao> Here is a short update on the traffic testing.
06:45:20 <anil_rao> The neutron client issue we had seen when the tap-service and tap-flow lists were empty is now gone. Looks like something got fixed in the latest DevStack
06:46:07 <reedip> cliff update
06:46:18 <anil_rao> Yes
06:46:43 <anil_rao> Some of reedip's patches are stuck but bringing them in manually fixes the issues they were designed for.
06:47:23 <anil_rao> I haven't tested the update commands, but they will not be necessary for the Summit demo.
06:47:39 <anil_rao> The other commands are working correctly, so the neutron client side looks great.
06:47:42 <reedip> they need +A now.... most of them are fixed, and the once which are not would have a merge conflict so I am awaiting the merge of current +2 patches
06:48:07 <anil_rao> reedip: I'll see to that tomorrow morning.
06:48:12 <reedip> sure
06:48:55 <anil_rao> yamamoto's latest review for removing the network parameter should get in. I'll complete that review too tomorrow.
06:49:15 <anil_rao> That should make things cleaner w.r.t. to the client usage.
06:49:21 <reedip> yup
06:49:53 <anil_rao> On the agent/driver side we have one problem.
06:50:30 <anil_rao> Upon start up it seems like the ML2 driver is wiping out the initial TaaS driver flows in br-tun.
06:50:53 <anil_rao> When I stop and restart the TaaS driver (manually) the TaaS flows come back.
06:51:18 <anil_rao> After that all is good. Traffic flows as expected when tap-flows are added to a tap-service instance.
06:51:39 <yamamot__> are you talking about https://bugs.launchpad.net/tap-as-a-service/+bug/1525775 ?
06:51:41 <openstack> Launchpad bug 1525775 in neutron "When ovs-agent is restarted flows creatd by other than ovs-agent are deleted." [Undecided,In progress] - Assigned to SUZUKI, Kazuhiro (kaz-k)
06:52:25 <anil_rao> Actually on my system this is noticed right after running stack.sh.
06:53:07 <anil_rao> I think after the TaaS driver has run its init routine the ML2 driver is cleaning somehing up.
06:53:49 <yamamot__> depending on the timing, i think it can be right after stack.sh.
06:53:49 <anil_rao> I want to get the demo setup ready for the Summit first. We can look into this later.
06:54:24 <reedip> you can restart TaaS in your stack.sh if you want a true hack
06:54:54 <reedip> that ways once stack.sh is completed and ML2 is almost over, you can restart TaaS service
06:54:55 <anil_rao> Its not a big deal for the moment, so I'll let it be. After I manually restart the TaaS agent all is fine.
06:55:12 <yamamot__> reedip: do you think l2 agent extension can be done anytime soon?
06:55:17 <reedip> you wont be able to start it via Dashboard :)
06:55:28 <reedip> yamamot__ I have studied the L2 extension spec
06:56:05 <reedip> yamamot__ do you know of any projects which have done similar migrations, I can take some hints from there as well
06:56:34 <anil_rao> The setup I have comprises of the following: 1 controller, 1 network, 2-3 compute
06:56:36 <yamamot__> i'm not aware of any, besides in-tree one (qos)
06:56:46 <anil_rao> Both local and remote port-mirroring is working.
06:57:06 <reedip> yamamot__ Ok, let me exp myself, and will ping you and other neutrinoes :)
06:57:10 <reedip> when I get stuck
06:57:44 <yamamot__> reedip: i _think_ it isn't too difficult.  but let's see. :-)
06:58:20 <reedip> yamamot__ I cannot say the same, whats easy for you may be an everest for me :)
06:58:27 <reedip> but atleast it would help me understand!
06:59:24 <anil_rao> We have two issues remaining:
06:59:47 <yamamot__> anil_rao: great to hear it still works regardless of the lack of automated tests
07:00:18 <anil_rao> Yes, suprising isn't it. I have been testing it through every now and then manually. :)
07:00:29 <anil_rao> A few remaining issues:
07:00:45 <anil_rao> 1. Interaction with anti-arp spoofing flows in br-int.
07:01:21 <anil_rao> Toward this we can discuss with the OVS agent externsion folks at the summit. I'll add an item to the design summit idea page
07:01:45 <anil_rao> 2. Problem with traffic capture when TaaS agent is running on the network node.
07:02:05 <anil_rao> This has to do with the use of vlans by the br-ex bridge.
07:02:33 <anil_rao> I'll look into this to see and try to find a fix.
07:04:11 <yamamot__> you might want to avoid br-ex.  eg. use flat provider network instead
07:04:17 <anil_rao> That should be it for the traffic update.
07:05:14 <anil_rao> yamamot_: OK
07:05:25 <yamamot__> wrt testing, i wrote a small utility and it was convenient for me during developement  https://review.openstack.org/#/c/301841/
07:06:46 <anil_rao> yamamot_: That is nice!
07:07:03 <kaz_> +1
07:07:09 <soichi> +1
07:07:22 <reedip> yeah, it was a pretty nifty creation
07:08:48 <anil_rao> soichi,kaz: I'll report back after I have the TaaS Dashboard hooked up. :-)
07:09:03 <kaz_> Yes, please
07:09:34 <anil_rao> #topic midonet implementation (crude but working)
07:09:59 <yamamot__> it's mine
07:10:08 <anil_rao> Yes.
07:10:32 <yamamot__> just fyi, i have another working implementation of taas api, backed by midonet.
07:10:53 <yamamot__> see the link on the agenda incase you're interested.
07:10:56 <yamamot__> that's all.
07:11:51 <anil_rao> yamamot__: What is the difference between the two versions, if I may ask?
07:13:20 <yamamot__> it's for midonet, which is completely different implementation of l2/l3.
07:13:36 <yamamot__> i tried to make it semantically equivalent of ovs impl.
07:13:50 <yamamot__> but there are small differences i guess.
07:14:49 <anil_rao> yamamot__: Thanks. Sounds good. Did you find any thing in the TaaS API that could be done differently/better.
07:15:27 <yamamot__> duplicated tap flows (a question i asked in the previous meeting)
07:15:40 <yamamot__> midonet impl does just work for those flows
07:16:30 <anil_rao> I would argue that they are not duplicated flows but different flows with same ports but mapping to different tap-services.
07:16:31 <yamamot__> so for midonet impl the current taas api is ok.
07:16:54 <anil_rao> Did I have that right?
07:17:14 <yamamot__> midonet impl just works even if they are completely same (same source and same dest)
07:17:45 <anil_rao> Why would you want same source to same dest done more than once?
07:18:28 <yamamot__> i don't know.  the current api allows tham and i had no reason to reject them.
07:18:48 <yamamot__> a difficulty was tapping "position" wrt security groups.
07:19:15 <anil_rao> However, that just consumes extra flows but doesn't provide any other benefit unless I am missing something.
07:19:46 <anil_rao> I think we should disallow that case.
07:20:15 <yamamot__> sure, i don't object if you want to reject such flows at api level or impl level.  i just stated a difference between midonet impl and ovs impl.
07:20:37 <anil_rao> Understand and agree.
07:20:55 <yamamot__> the current tapping position is from the implementation detail of ovs and was not suitable to midonet impl.
07:21:14 <anil_rao> I think what we should be supporting instead is same source port and multiple tap-service instances. I plan to add that support for OVS.
07:21:15 <yamamot__> many of work in midonet side was to overcome the difference.
07:22:24 <yamamot__> anil_rao: it works for midonet as well
07:22:25 <anil_rao> I think we should rethink the tapping position. Any idea if/when Security Groups will come out of the Linux bridge
07:23:04 <anil_rao> yamamot__: I am glad you have that working. We need that on OVS too. :-)
07:24:21 <anil_rao> Its good to see another backend implementation for TaaS.
07:24:27 <yamamot__> anil_rao: i guess it's mostly impossible as far as SG is implemented in LB.  we need flow-based SG.
07:24:46 <anil_rao> yamamot__: +1
07:25:12 <yamamot__> fortunately flow-based SG is actively being worked on these days
07:25:44 <anil_rao> yamamot__: That is great! Perhaps we should interact with those folks at the summit.
07:26:22 <anil_rao> Let's move to open discussion
07:26:29 <anil_rao> #topic Open Discussion
07:27:36 <anil_rao> What do folks think about moving the TaaS IRC meeting one hour earlier.
07:27:51 <yamamot__> fine for me
07:27:57 <anil_rao> With the change to summer/daylight time it is quite late here in the US.
07:28:12 <soichi> no problem for me, too
07:28:18 <kaz_> ok
07:28:33 <anil_rao> Vinay also prefers it because of their time change (Sweeden)
07:28:44 <yamamot__> i'm glad we have no daylight saving here :-)
07:29:00 <anil_rao> yamamot__: :-)
07:29:39 <anil_rao> OK, we are out of time for today. We'll continue next week.
07:29:56 <anil_rao> #endmeeting