06:36:29 <vnyyad> #startmeeting Tap as a Service Meeting
06:36:30 <openstack> Meeting started Wed Nov 11 06:36:29 2015 UTC and is due to finish in 60 minutes.  The chair is vnyyad. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:36:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:36:34 <openstack> The meeting name has been set to 'tap_as_a_service_meeting'
06:36:40 <vnyyad> started now
06:37:09 <vnyyad> so lets dive into the agenda
06:37:30 <vnyyad> i guess we got the intro from all present now
06:37:56 <vnyyad> next up the status of the project
06:37:58 <anil_rao> Its great to see all the new folks. Welcome to TaaS :)
06:39:12 <vnyyad> i guess most of you were in the tokyo summit are appraised of the status
06:40:19 <anil_rao> At the summit we entered serveral immediate work items into etherpad
06:40:30 <elady> Please sync, on current status
06:41:58 <anil_rao> https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track (see Tap-as-a-Service)
06:42:33 <amotoki> is this the meeting agenda? https://wiki.openstack.org/wiki/Meetings/taas
06:42:56 <vnyyad> amotoki: yes it is
06:43:29 <amotoki> vnyyad: thanks
06:43:57 <yamamoto> #link https://wiki.openstack.org/wiki/Meetings/taas Agenda
06:44:23 <vnyyad> We currently have a basic version of TaaS with core features of port mirroring on a OVS switch implemented
06:45:53 <vnyyad> Thanks to contributions from yamamoto in the recent months we have some  unit test cases for TaaS
06:47:12 <vnyyad> yamamoto: could you give a short description of the work you and others have added to TaaS recently
06:48:03 <yamamoto> i added unit tests for plugin.  someone needs to write tests for agent-side.
06:48:23 <vnyyad> ok
06:48:26 <yamamoto> i have halfly baked devstack plugin.  i think i will finish it in near future.
06:48:43 <vnyyad> yamamoto: thanks
06:49:29 <vnyyad> i guess the list prepared in the tokyo summit server as a good next step for TaaS (https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track)
06:50:32 <vnyyad> i guess we need to prioritize the activities in that
06:51:25 <dedery_> as i recall, the number one priority was to get into Neutron's big-tent (thus be in the safe zone from breakage)
06:51:43 <anil_rao> Agree
06:51:57 <vnyyad> i agree
06:52:03 <ktatsuro> +1
06:52:14 <anil_rao> We have some items identified under 'Big Tent requirements' section
06:52:36 <vnyyad> Devstack automation
06:52:49 <amotoki> +1. In addition, from the point of view of subproject management, it is better to have a portal doc/wiki page.
06:53:39 <amotoki> I am not sure all attendees to this meeting are aware of all resources (urls) or not.
06:54:16 <amotoki> sorry for interruptiing. please go ahead
06:54:33 <vnyyad> amotoki: will add creation of wiki page to the todo list
06:54:49 <amotoki> vnyyad: sounds perfect
06:55:05 <yamamoto> i don't think wiki is a good idea.  it's better to concentrate to in-tree doc.
06:55:20 <vnyyad> next this for Big Tent req is the automated testing
06:56:30 <yamamoto> i can write skeleton tempest plugin so that others can write actual tests.
06:57:15 <vnyyad> yamamoto: this will be good, i guess we can all pitch in with writing the test cases
06:57:19 <vnyyad> thanks
06:57:39 <yamamoto> and we need agent coverage of unit tests.  any takers?
06:58:44 <dedery_> i can take. what kind of tests?
06:59:08 <dedery_> at Tokyo we've talked about static analysis of the generated flows
06:59:38 <dedery_> which i assume should be part of the agent tests (since its the one settings the flows) isn't it?
07:01:18 <yamamoto> i was talking about unit tests.  i'm not sure about static flow analysis.
07:01:22 <anil_rao> The actual flows are programmed into OVS by the TaaS driver
07:01:42 <vnyyad> and tass driver is invoked by the agent
07:02:02 <elady> I can take the API checks
07:02:54 <vnyyad> elday: thanks
07:03:18 <dedery_> I can take the unit tests
07:03:18 <vnyyad> I can help out in that as well
07:04:20 <elady> E2E tests ? later?
07:04:44 <tamar> I'd like to help with the E2E
07:05:01 <dedery_> E2E should be part of the tempest/API tests no? (same context)
07:06:13 <reedip> I would also like to help out with the Unit test cases
07:06:19 <yamamoto> it doesn't need to be, but i think tempest is the best choice at this point.
07:07:27 <vnyyad> thanks dedery_ and reedip
07:07:46 <anil_rao> I feel there are a few items that we should also be considering as an immediate goal in addition to the tests
07:08:41 <anil_rao> Two of these are: ensuring basic error handling and restoring flows upon TaaS agent restart
07:09:14 <anil_rao> Nothing covering these often leads to bad situations in case a node dies
07:09:23 <vnyyad> i can take the error handling part
07:09:39 <anil_rao> i'll look into restoring the flows
07:10:38 <anil_rao> As a background activity we should also be discussing 'resource reservation' so that we can take this up with the core Neutron team
07:10:58 <anil_rao> I think that is necesary in order to come under the Big Tent
07:11:09 <vnyyad> anil_rao: i agree
07:11:40 <vnyyad> was there some discussion around this with the core (formally or otherwise) with the cores?
07:11:49 <vnyyad> at the summit
07:12:00 <anil_rao> i did get a chance to briefly discuss this with Armando
07:12:37 <anil_rao> His take was that this is a problem seen by a few other projects outside of just TaaS. We might have to have a discussion on this in the main
07:12:51 <anil_rao> Neutron mailing list of in the Neutron IRC chat.
07:13:00 <vnyyad> ok
07:13:35 <vnyyad> i guess we can first take a call on how this should be done and then take the discussion with the cores... any thoughts
07:13:53 <anil_rao> The current code essentially disables 'anti arp spoofing'. We'll have to co-ordinate OVS table entries to ensure that both projects work well together.
07:13:59 <elady> In the summit we talked about using "on demand allocation" of resources and also alternative option of using MPLS encapsulation.
07:14:38 <elady> the "on demand" should be easy, I haven't got to investigate the MPLS thing
07:15:13 <elady> but the idea is to encapsulate the mirrored traffic in the same manner SFC does
07:15:46 <anil_rao> we must however be careful to preseve the isolation guaratees of mirrored traffic (not only from production traffic but other TaaS service instances)
07:16:44 <anil_rao> In my opinion whichever way we proceed we'll need to co-ordinate with other projects to ensure that mirrored traffic is not visible to anyone outside the destination port of a TaaS service instance
07:16:46 <soichi> i agree
07:16:51 <elady> agree
07:16:58 <vnyyad> +1
07:17:23 <ktatsuro> +1
07:17:43 <vnyyad> anil: should we have this resolved before we get into the Big Tent
07:17:53 <amotoki> more generally speaking, we need to define the order of applying various services: SFC, TaaS, QoS, ...
07:18:09 <amotoki> the same topic was raised in the context of SFC disucssion.
07:18:12 <reedip> +1
07:18:19 <elady> +1
07:18:34 <anil_rao> vnyyad: We need to discuss this as a group and make a proposal that we can present to the Neutron core team.
07:18:51 <vnyyad> anil_rao: i agree
07:19:05 <anil_rao> We don't need to have it all implemented rightaway but I feel that this question will come up when a decision to include TaaS in the big tent is being made
07:19:17 <vnyyad> yes
07:20:19 <anil_rao> Armando had mentioned to me that this issue was being faced by several other projects such as kuryer, SFC, IP networks, etc.
07:21:11 <vnyyad> do we need to coordinate or atleast watch out for the approaches they take?
07:21:43 <anil_rao> Yes, we should be watching activity around this on the core Neutron mailing list and IRC channels
07:22:06 <vnyyad> ok
07:22:47 <vnyyad> i guess we have enough activities to get started on targeting the Big Tent
07:22:57 <anil_rao> Yes :)
07:23:32 <dedery_> looks like it :)
07:23:58 <dedery_> i'd like to address the blueprint at some point if it's possible
07:24:25 <vnyyad> dedery_: sure
07:25:01 <vnyyad> just to be sure can everyone who took up some activity repeat what they will look into
07:25:34 <dedery_> adding unit tests
07:25:35 <vnyyad> Error handling
07:25:44 <yamamoto> devstack and tempest plugin
07:25:51 <anil_rao> Restore flows upon Agent restart
07:27:30 <vnyyad> ok then we can get going on these onces to start with
07:28:34 <vnyyad> anything else to be discussed today
07:28:41 <dedery_> there was another task which we've talked about but it's not mentioned in etherpad - the "productization" of the agent and plugin (making it a service and not a manual script if i recall. anil_rao do you remember?)
07:29:02 <anil_rao> Yes.
07:29:44 <yamamoto> "service" in which sense?
07:29:59 <anil_rao> We essentially need the TaaS agent to get launched automatically
07:30:13 <anil_rao> It is currently started manually from a shell script
07:30:16 <vnyyad> haa ok yes
07:31:27 <yamamoto> my impression is that taas agent should be turned into an agent extension driver eventually.
07:31:29 <anil_rao> I can look into this
07:32:01 <anil_rao> I guess we are out of time.
07:32:07 <vnyyad> yes
07:32:17 <dedery_> yeh, i'll keep my blueprint questions for next time :)
07:32:19 <irenab> yamamoto: +1 on agent extension driver
07:32:54 <yamamoto> i guess we already have enough work for a week.
07:33:00 <irenab> similar pattern to QoS agent extension
07:33:26 <yamamoto> irenab: indeed
07:33:33 <vnyyad> we can add this discussion on driver extension to next weeks agenda
07:33:43 <anil_rao> Yes
07:34:03 <vnyyad> i guess we are out of time
07:34:26 <anil_rao> Thanks everyone.
07:34:29 <yamamoto> thank you
07:34:31 <dedery_> thank you
07:34:33 <soichi> see you
07:34:37 <vnyyad> thanks for everyone for participating. We got a good list of work to start off with
07:34:56 <vnyyad> thanks and see you
07:35:37 <dedery_> vnyyad: i think that you should use the #endmeeting now
07:35:51 <vnyyad> thanks for pointing it out :)
07:35:59 <vnyyad> bye all
07:36:06 <vnyyad> #endmeeting