06:30:13 <anil_rao> #startmeeting taas
06:30:14 <openstack> Meeting started Wed Feb  3 06:30:13 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:30:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:30:17 <openstack> The meeting name has been set to 'taas'
06:30:38 <anil_rao> Hi
06:31:03 <reedip> o/
06:31:07 <kaz> hello
06:31:33 <reedip> who else left to join ?
06:32:01 <anil_rao> Lets get started
06:32:16 <irenab> hi, I am here (mostly listening :-) )
06:32:23 <vnyyad> Hi
06:33:16 <reedip> Okay, so shall we start ?
06:33:42 <anil_rao> Sure.
06:33:54 <vnyyad> yes
06:34:17 <reedip> anil_rao, you can start of with the agendas :)
06:34:49 <anil_rao> Yes, lets start with the 1st item, which is spec discussion
06:35:08 <vnyyad> #topic update the spec with use cases
06:35:13 <reedip> #link https://wiki.openstack.org/wiki/Meetings/taas
06:35:25 <muawiakhan> hi
06:35:38 <reedip> hello muawiakhan ...
06:35:59 <reedip> so thanks to Fawad, we have been able to restart the Spec topic
06:36:25 <vnyyad> thanx Fawad
06:36:33 <reedip> and there have been some useful comments provided ... as vnyyad listed, we need to add more specific use cases in it
06:37:48 <yamamoto> vnyyad: iirc #topic command is chair-only
06:38:01 <reedip> #link https://review.openstack.org/#/c/256210/4/specs/mitaka/tap-as-a-service.rst
06:38:19 <vnyyad> yamamoto: yes i guess anil needs to do it
06:38:22 <anil_rao> #topic spec discussion
06:38:50 <reedip> currently the spec lacks the exact scenarios which would be applicable
06:38:57 <anil_rao> folks please feel free to jump in. I have been out of town for a couple of weeks so I am essentially catching up on things.
06:39:36 <reedip> on a high level we do have some specifications mentioned, but we need to start streamlining them for the M release, considering M has only about ( or less than a month) to go
06:40:34 <anil_rao> Are there any specific items we can discuss in this meeting?
06:40:34 <reedip> vnyyad anil_rao yamamoto: any specific use cases which you can consider for TaaS, woth respect to the current API spec?
06:41:22 <anil_rao> reedip: I am not sure I fully understand this requirement. The use cases can be quite diverse so what are we actually looking for?
06:42:12 <reedip> anil_rao : What my intention is to streamline the REST API spec. That would allow us to freeze some of the conditions and possible support early on
06:42:38 <reedip> anil_rao : REST API spec would continue to change till we do not have a major chunk of use cases with us
06:43:30 <anil_rao> After reading the latest updates to the spec I see a lot of new requirements, for example metadata generation.
06:43:43 <reedip> anil_rao : currently TaaS still is not integrated with governance, and to ensure that it does, it would be great if we can convince the Neutron core members about the use cases which we have handled
06:43:53 <reedip> anil_rao: yes, that was something which is new
06:44:31 <anil_rao> In my opinion, a lot of these new requirements can be handled a future extensions. I am not sure we need to nail all such requirements at this time.
06:45:11 <reedip> anil_rao : yeah, thats true, but then can we finalize the requirements targetted for this version ?
06:45:49 <anil_rao> the basic requirement, IMHO, is collecting packets ingressing/egressing Neutron ports and having them delivered to a designated port to which a monitoring VM can be attached. Do folks feel this is not sufficient?
06:46:14 <soichi> anil_rao: +1
06:46:53 <reedip> +1  for simplification :)
06:47:04 <kaz> +1
06:47:06 <vnyyad> +1
06:47:41 <anil_rao> Once we have that basic capability we can implement all sort of interesting solutions on top of that. I believe the actual use case will be very specific to the service provider and/or tenant using TaaS
06:47:41 <yamamoto> i agree that it makes more sense to fix issues (eg. uuid stamp things) than adding more features at this point of cycle.
06:48:37 <reedip> agreed
06:48:44 <vnyyad> anil_rao +1
06:50:26 <anil_rao> Now that I am back I'll examine the spec and post some comments/suggestions there
06:51:28 <reedip> +1
06:51:36 <soichi> +1
06:52:04 <muawiakhan> sounds good, we can make it an action item for fawad and yamamoto to address those.
06:52:43 <anil_rao> A question: I see some discussion regarding whether the tap-service port (destination of the mirror) should be created by TaaS or provided as an input. Any thoughts on this?
06:53:05 <reedip> anil_rao: both
06:53:31 <reedip> anil_rao: Desitnation port can either be a spare port which user has already created, and would now use for monitoring.
06:53:43 <muawiakhan> +1
06:53:52 <reedip> anil_rao: or if he does not provide a port, then allocation via neutron should be made possible
06:54:11 <reedip> anil_rao: would give flexibility to the user
06:54:47 <vnyyad> anil_rao: Both
06:54:58 <anil_rao> ok
06:55:46 <anil_rao> If TaaS is instantiating the port, we will need to take in the network id I guess.
06:55:58 <reedip> anil_rao : would impact the current code, but I guess most of the exception handling would be done by neutron and therefore , we just need to catch it ...
06:56:27 <reedip> anil_rao: I think network is necessary, even if the port is passed
06:57:21 <vnyyad> anil_rao, reedip: we also need to create the new port with security groups disabled, as we do in the case today externally
06:57:27 <reedip> anil_rao: but if a port  which is a destination for monitoring traffic is detached from a network and attached to another one, would the monitoring continue?
06:57:38 <anil_rao> reedip: Why is the network id necessary if the port is passed in?
06:58:26 <reedip> anil_rao : considering the scenario I explained just right now
06:59:39 <anil_rao> In the reference OVS implementation we forward the traffic to the destination port (specified) without worrying about the network it is attached to. I am not sure why the network is necessary here, unless TaaS is creating the port.
07:00:17 <vnyyad> anil_rao: +1
07:00:48 <reedip> anil_rao : if detaching the port from the network and attaching it to the a new network does not impact the monitoring, then network_id and port_id can be optional while creating tap_service
07:01:38 <yamamoto> reedip: can you explain "detaching the port from the network"?
07:01:40 <reedip> correction -> if port_id is not provided, network_id would suffice
07:02:23 <anil_rao> Yes, we should take in one of the two.
07:02:44 <muawiakhan> agreed
07:03:22 <anil_rao> Lets move to the next topic
07:04:28 <anil_rao> #topic l2-agent-extensions-agent-api
07:05:02 <yamamoto> #link https://review.openstack.org/#/c/267591/
07:05:19 <reedip> yamamoto : just confirmed what you were saying, my bad... it is not possible
07:06:16 <yamamoto> l2 agent extensions patch is in review.  i encourage everyone here to review it.
07:06:33 <yamamoto> reedip: i see.  thank you for confirming
07:06:52 <anil_rao> yamamoto: Thanks for the reminder
07:07:53 <yamamoto> let's move on
07:08:05 <anil_rao> to next topic?
07:08:09 <yamamoto> yes
07:08:23 <anil_rao> #topic Summit Presentation
07:09:12 <anil_rao> We have submitted a tech-talk proposal on TaaS for the Austin Summit
07:09:41 <anil_rao> This will essentially be a review of the the project including the current development activity.
07:09:52 <reedip> +2
07:10:02 <anil_rao> I would also like for us to get a demo in as part of this if we are selected
07:10:20 <soichi> +1
07:10:42 <anil_rao> We will use this opportunity if it becomes available to describe some representative use cases.
07:11:15 <vnyyad> anil_rao: +1
07:11:20 <kaz> +1
07:11:56 <anil_rao> Please spread the word so that we get enough votes. :-)
07:12:38 <reedip> anil_rao : selection will open 7 days from now :)
07:13:07 <anil_rao> We should also plan for the Design Summit and try to get a slot
07:13:54 <soichi> i will ask my colleague to add "+1".
07:13:57 <reedip> anil_rao : I think that would be in discussion with the Neutron PTL ( armax )
07:14:39 <anil_rao> Shall we move to the next item?
07:15:37 <yamamoto> yes
07:15:44 <anil_rao> #topic Action items from last meetings
07:16:10 <yamamoto> i have no updates for "testing related scenarios"
07:17:00 <anil_rao> Question to all: Has anyone tried running TaaS in a full openstack environment (i.e. non DevStack)
07:17:01 <reedip> me neither ...
07:17:51 <yamamoto> anil_rao: what do you mean by "full"?  multinode?
07:19:18 <anil_rao> yamamoto: I was refering to installing TaaS in an existing OpenStack cloud (say one that is created following the Ubuntu OpenStack installation guide)
07:20:11 <kaz> I have tried to run TaaS on RDO packstack environment.
07:21:04 <anil_rao> I will look into this and report back here in a subsequent meeting
07:22:04 <anil_rao> Any update on L2 extension for TaaS
07:22:51 <reedip> anil_rao : not started yet, will review the api extension recommended by yamamoto
07:22:53 <vnyyad> vnyyad: no, will start the work soon
07:23:03 <reedip> first, then will start it with vnyyad
07:23:18 <vnyyad> vnayyad, reedip:  first review
07:23:39 <reedip> yup :)
07:23:49 <anil_rao> Thx
07:24:39 <anil_rao> More core reviewers?
07:24:55 <vnyyad> ani_rao: Good Idea
07:25:45 <reedip> yup
07:25:52 <reedip> anil_rao: yup
07:26:37 <anil_rao> regarding the two +2 rule, I am for it.
07:26:45 <reedip> but for that I guess we would need recommendation and voting, as is done in all other modules
07:27:10 <vnyyad> anil_rao: +2, we must sort this out soon
07:27:32 <anil_rao> vnyyad: Yes.
07:28:15 <anil_rao> We are running out of time. Any open items off the list?
07:28:37 <yamamoto> Performance_Evaluation_20160203-01.pdf link seems broken
07:28:57 <anil_rao> kaz: Any update on this?
07:29:03 <soichi> i will check it.
07:29:20 <kaz> I can see this link.
07:30:12 <reedip> any items left ? we are past the alloted time
07:30:21 <anil_rao> Let us discuss this next week. Our time for today is up.
07:30:25 <soichi> kaz: what do you say to carry over to next week?
07:30:41 <anil_rao> Yes, lets do that
07:30:47 <kaz> ok
07:31:01 <anil_rao> #endmeeting