06:30:26 <vnyyad> #startmeeting taas
06:30:27 <openstack> Meeting started Wed Dec 16 06:30:26 2015 UTC and is due to finish in 60 minutes.  The chair is vnyyad. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:30:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:30:30 <openstack> The meeting name has been set to 'taas'
06:30:48 <anil_rao> Hi
06:31:10 <vnyyad> #topic let's revive spec discussion https://review.openstack.org/#/c/256210/
06:31:39 <vnyyad> thanks for getting the spec revived
06:31:51 <reedip> Hello
06:31:57 <yamamoto> #link https://wiki.openstack.org/wiki/Meetings/taas agenda
06:32:34 <reedip> vnyyad, yamamoto, anil_rao : I thought of creating an etherpad to verify the status..
06:32:50 <yamamoto> reedip: status of what?
06:32:57 <reedip> vnyyad, yamamoto, anil_rao : Just FYI
06:33:28 <reedip> yamamoto: status of progress of the various discussions and development ongoing
06:33:29 <reedip> https://etherpad.openstack.org/p/Tap-as-a-Service
06:33:45 <yamamoto> #link https://etherpad.openstack.org/p/Tap-as-a-Service
06:33:58 <vnyyad> reedip: Ok
06:35:16 <vnyyad> I guess there are some who have comments, suggestion and issues with spec
06:35:38 <anil_rao> Can we discuss some of these issues here
06:35:39 <vnyyad> it would be good if they participated and discussed it here in the meeting
06:36:22 <reedip> vnyyad: we can extend an invitation to them next week at the scheduled time  ...
06:36:32 <vnyyad> sure
06:36:49 <vnyyad> when we comment on the spec, we can leave a note there toward the meeting
06:36:49 <reedip> meanwhile, as anil_rao mentioned, we can probably discuss them.... and drop a mail to ML after the meeting is over
06:37:07 <vnyyad> reedip: sure
06:37:53 <reedip> #action vnyyad to drop a mail to the ML for discussing TaaS spec next week, if holidays are not an issue
06:38:42 <vnyyad> reedip: I can drop a mail irrespective, if we meet after the holidays that too is good
06:38:55 <reedip> ok :)
06:39:24 <vnyyad> ok lets start with the issue we want to discuss, lets bring them up now
06:41:28 <vnyyad> discussion around API completeness brought up by Fawad
06:41:49 <vnyyad> any comments from other on it
06:42:37 <anil_rao> My thoughts are that we go with a minimal API that is resonably complete, otherwise we won't make it into any release
06:43:06 <soichi> +1
06:43:43 <vnyyad> i guess we can iterate over the APIs in the future, its not set in stone and that should not stall the progress of the spec for now
06:43:48 <yamamoto> +1 as far as the functionality can be added later (as an extension)
06:43:50 <reedip> Yup, +1 ... making it heavy early on does not make too good a sense
06:45:49 <vnyyad> we have a -1 now regarding the issue, i guess having them discuss this in the meeting is essential
06:46:46 <yamamoto> vnyyad: you think discussion on gerrit doesn't work?
06:47:23 <vnyyad> yamamoto: it does for sure, but getting them to meeting also helps was my view
06:48:08 <anil_rao> yamamoto: Gerrit discussions work but we should also get on the same page w.r.t. shorter term goals. I am not sure how to specify that in the spec without raising concerns about the scope of the project.
06:50:17 <anil_rao> From the beginning of the TaaS spec review, folks have been eying it with both short term and long term (ideal case) goals in mind. This would lead to us going round and round and not making much progress. Does anyone have thoughts on how to break  the cycle?
06:51:07 <vnyyad> anil_rao: +1
06:51:44 <yamamoto> how about having "feature direction" or "optional features" in the spec?
06:52:25 <anil_rao> That sounds interesting. Can you please elaborate some more?
06:52:54 <reedip> yamamoto : something like scope for Mitika and for Newton ???
06:53:09 <reedip> ( considering N is going to Newton )
06:53:32 <yamamoto> as commented on the review, there seems to be people who want non-minimam functionalities
06:53:35 <yamamoto> (including me9
06:54:47 <yamamoto> so having optional goals might makes sense.  say, "the initial implementation might or might not have these..."
06:55:35 <yamamoto> reedip: yes, sort of.
06:55:46 <vnyyad> yamamoto: +1, this is good to be added in the spec
06:56:37 <soichi> +1
06:56:46 <vnyyad> the scope for the mitika has to be clearly marked off to get the spec and work going
06:56:46 <anil_rao> I keep wondering if there is a minimal set that everyone agrees on for the first release. If we are all striving toward a common goal this sholdn't be hard to define.
06:56:48 <reedip> yamamoto: We can add that information in the spec.. would be great to make up the goals
06:56:55 <dedery_> yamamoto: +1 setting the expectations is appriciated.
06:58:26 <yamamoto> anil_rao: sure, let's define the minimal set and set it for mitaka.  the rest will go into the optional category.
06:59:46 <vnyyad> so we agree to have a section in the spec to address this
07:00:00 <vnyyad> all on board :)
07:00:55 <reedip> +1
07:01:11 <kaz> +1
07:01:56 <vnyyad> next issue was from bao wang regarding traffic loss in the mirrored traffic
07:05:36 <vnyyad> This is a interesting problem
07:06:43 <vnyyad> any thoughts
07:06:46 <anil_rao> I am not sure I fully understand Bao's concern here. Why is it felt that any traffic loss (no matter how small) will make monitoring unreliable?
07:07:02 <yamamoto> i wonder what level of reliability he needs.
07:07:47 <reedip> I think it may be possible that the loss of mirrored traffic is the traffic which is intruding in the system
07:08:13 <reedip> I mean the intruding traffic somehow didnt get mirrored , and thus was not observed, and went undetected
07:09:06 <yamamoto> i guess it's better to ask him rather than guessing here.
07:09:54 <dedery_> let's assume for a moment that this is an issue. What are the possible ways to deal with this?
07:10:32 <yamamoto> some sort of flow control?
07:10:55 <dedery_> QoS for tapped traffic?
07:11:38 <anil_rao> Mirrored packets flowing over a network in the GRE tunnel or VxLAN tunnel can suffer losses. I don't think flow control will take care of that.
07:12:34 <anil_rao> I believe Bao is more worried about the GRE tunnel portion or our solution than the mirroring action as such.
07:14:06 <vnyyad> let us get it clarified from him on this
07:14:15 <anil_rao> Yes
07:15:01 <yamamoto> how about going over the rest of topics quickly before we use the whole meeting for spec discussion?
07:15:13 <anil_rao> Sure
07:15:16 <vnyyad> sure
07:15:33 <vnyyad> #topic we ought to maintain "two +2s to merge" rule
07:16:15 <yamamoto> it's the rule the most of openstack projects maintain
07:16:29 <vnyyad> yamamoto: i agree
07:16:37 <yamamoto> we ought to try to follow.
07:16:39 <anil_rao> +
07:16:42 <anil_rao> +1
07:16:47 <dedery_> +1
07:17:09 <vnyyad> does it need some support from infra to get this in our project
07:17:12 <reedip> +1
07:17:38 <yamamoto> vnyyad: ?
07:18:32 <vnyyad> yamamoto: please ignore :)
07:18:37 <vnyyad> i got it wrong
07:18:44 <yamamoto> vnyyad: there are no mechanical policy enforcement in other projects.  the rule is merely maintained by human beings.
07:19:16 <vnyyad> yamamoto: got it
07:20:00 <vnyyad> #topic have a dedicated irc channel?
07:20:17 <yamamoto> i was wondering if we want to have our own irc channel
07:20:25 <yamamoto> like #tap-as-a-service
07:20:30 <yamamoto> how do you think?
07:20:51 <reedip> vnyyad : I guess its not required right now... maybe once it has evolved a bit more?
07:21:24 <yamamoto> it can be useful for eg. gerrit notifications
07:21:58 <yamamoto> eg. a patch is proposed, merged, etc
07:22:14 <anil_rao> Sounds good to me
07:22:40 <reedip> as such, I think its good to have
07:22:49 <vnyyad> yamomoto: +1
07:22:59 <yamamoto> ok, let me try to set it up
07:23:14 <vnyyad> yamamoto: thanks
07:23:38 <vnyyad> #topic neutron ovs-agent deletes taas flows (cont.)
07:23:49 <soichi> yamamoto, reedip: thank you for your comments on the patch Kaz submitted
07:23:57 <soichi> Kaz submitted a patch based on our idea that I submitted to mailing list.
07:24:03 <soichi> link: http://lists.openstack.org/pipermail/openstack-dev/2015-December/082372.html
07:24:19 <soichi> i think it is better to use ml2 extention API (under discussion) as Ihar suggested.
07:24:26 <soichi> link: http://lists.openstack.org/pipermail/openstack-dev/2015-December/082303.html
07:24:41 <irenab> yamamoto: regarding the channel name, shouldn’t it be prefixed with ‘openstack’?
07:25:04 <reedip> vnyyad, anil_rao, everyone: There are some patches currently pending review on https://review.openstack.org/#/q/status:open+project:openstack/tap-as-a-service,n,z.. if you have some time, please look into the same
07:25:13 <reedip> oh sorry, I thought the channel was open
07:25:49 <yamamoto> irenab: suggestions are welcome :-)
07:26:04 <vnyyad> reedip: shall do
07:26:26 <anil_rao> reedip: Will do
07:26:53 <yamamoto> any volunteer to turn our agent to l2 extension?
07:27:04 <irenab> yamamoto: :-), it just looks like convention. We followed this for kuryr channel. but this just a suggestion
07:27:09 <yamamoto> related bug https://bugs.launchpad.net/tap-as-a-service/+bug/1515104
07:27:09 <openstack> Launchpad bug 1515104 in tap-as-a-service "taas agent relies on ovs-agent" [Undecided,New]
07:27:56 <reedip> yamamoto: I can give it a try  to convert to an L2 extension
07:28:09 <vnyyad> yamamoto: +1
07:28:19 <vnyyad> reedip: i can join in too
07:28:31 <yamamoto> reedip: vnyyad: thank you!
07:28:38 <reedip> #action: vnyyad and reedip to take up L2 extension for TaaS
07:29:08 <reedip> #action anil_rao and vnyyad would take up the currently pending reviews for TaaS
07:29:20 <vnyyad> reedip: +1
07:29:27 <vnyyad> any other business?
07:29:41 <kaz> I have a question.
07:29:53 <kaz> I guess a test scenario would be as follows:
07:30:02 <kaz> 1. create a flow whose cookie=0x0 if there is no flow whose cooki=0x0
07:30:24 <kaz> 2. record a list of flows
07:30:31 <kaz> 3. restart ovs agent
07:30:39 <kaz> 4. deploy a vm (to run the cleanup logic)
07:30:46 <kaz> 5. confirm flows whose cookie=0x0 were not deleted
07:30:52 <kaz> I have no idea how to write this kind of test in acceptable format for jenkins.
07:31:24 <yamamoto> fullstack or functional test?
07:31:39 <kaz> functional test
07:32:24 <yamamoto> i'm not sure what's your concern
07:32:43 <yamamoto> we run out of time.
07:33:00 <vnyyad> lets  take it up in the mailing list
07:33:05 <vnyyad> we are out of time now
07:33:06 <reedip> kaz: you need to use normal neutron CLIs to do that work
07:33:11 <kaz> I will ask offline.
07:33:18 <vnyyad> thanks everyone
07:33:24 <vnyyad> bye
07:33:29 <yamamoto> bye
07:33:29 <dedery_> bye :)
07:33:29 <reedip> ok... Happy holidays :)
07:33:31 <kaz> bye
07:33:31 <soichi> bye
07:33:32 <anil_rao> Bye
07:33:53 <vnyyad> #endmeeting