06:33:45 <vnyyad> #startmeeting taas
06:33:46 <openstack> Meeting started Wed Mar  2 06:33:45 2016 UTC and is due to finish in 60 minutes.  The chair is vnyyad. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:33:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:33:50 <openstack> The meeting name has been set to 'taas'
06:33:59 <vnyyad> Hi all
06:34:01 <soichi> hi
06:34:05 <kazu> hello
06:34:11 <yamamoto> hi
06:34:47 <vnyyad> since there is no fixed agenda today... anyone wants to bring up something?
06:35:50 <reedip> Well , I was going through the various TaaS related lonks
06:35:52 <reedip> links*
06:36:46 <reedip> #link https://review.openstack.org/#/c/96149/8/specs/juno/tap-as-a-service.rst
06:36:58 <reedip> this had some very important points of discussion
06:37:10 <reedip> when TaaS was floated in Juno
06:37:34 <anil_rao> reedip: anything in particular?
06:37:55 <reedip> anil_rao : have to compare it once more, will share the same in the ML
06:38:03 <reedip> by today/tomorrow
06:38:15 <vnyyad> reedip: sure
06:38:37 <anil_rao> OK
06:38:46 <reedip> anil_rao, vnyyad : we would also maybe need to decide on certain milestones once our spec is released
06:39:03 <reedip> to keep track of what are the various things which we need to do and which the users require
06:39:21 <reedip> for that we may need to maintain a wiki page ( yamamoto, correct me if I am wrong )
06:40:16 <anil_rao> A good first milestone (which we somewhat discussed in Tokyo) was getting the current implementation solidified.
06:40:25 <yamamoto> we need to maintain the info, yes
06:40:26 <anil_rao> I.e. handle bugs and corner cases.
06:40:50 <anil_rao> I am going through the paces of using TaaS and have a few things to report.
06:41:27 <yamamoto> anil_rao: and have automated tests
06:41:46 <anil_rao> yamamoto: +1
06:41:53 <reedip> yamamoto : +1
06:42:10 <soichi> +1
06:42:18 <reedip> I was also going through the other proposed TaaS options, and found this
06:42:22 <reedip> #link: https://review.openstack.org/#/c/106236/1/specs/juno/bsn-taas.rst
06:42:32 <reedip> again a Juno Spec
06:43:07 <reedip> this was discontinued, but displayed an option which can be taken up in the future ... just mentioning it here, so that we have a track of the spec
06:43:09 <vnyyad> reedip: nothing much happened after the spec or on the spec as well
06:44:04 <vnyyad> anil: you wanted to report some findings
06:44:17 <anil_rao> Looks like they are talking about a Big Switch backend (plugin + driver) behind TaaS.
06:44:17 <reedip> vnyyad: yeah I noticed it, and was trying to get some info from kevin, but Mitaka Release is here... :(
06:44:27 <reedip> anil_rao : yes
06:44:28 <yamamoto> reedip: isn't it just about a vendor impl of taas?
06:44:45 <reedip> yamamoto: yes , seems so
06:44:50 <vnyyad> yamamoto: yes
06:45:05 <yamamoto> if bsn is still interested in implementing, there's nothing prevent it i guess.
06:45:13 <vnyyad> +1
06:45:32 <vnyyad> yamamoto: actually good i would say
06:45:32 <anil_rao> Yes, they are most welcome to implement a backend on the TaaS API.
06:45:57 <reedip> yeah, would increase exposure
06:46:14 <yamamoto> we might want to split some part of plugin into a driver for easier vendor impl though.
06:47:09 <reedip> yamamoto : it may be required in the future, if someone does want to implement
06:48:12 <yamamoto> i guess i will do it for midonet impl by myself, but if someone want to beat me, be my guest. :-)
06:48:58 <reedip> :)
06:49:08 <vnyyad> :)
06:49:26 <reedip> anil_rao : you had some findings
06:49:32 <reedip> could you share the same
06:49:39 <anil_rao> reedip: Sure.
06:50:05 <anil_rao> I was testing the neutron client with taas extensions. Here are some findings.
06:50:30 <anil_rao> Environment: multi-node devstack, 1 controller, 2 compute nodes
06:50:58 <anil_rao> I had to pull in some of reedip's patches to get tap-service-create working.
06:51:42 <anil_rao> tap-service list only works if a tap-service exists. If no tap-services are there the call returns 'list index out of range'
06:51:54 <anil_rao> the same if true of tap-flow-list if no tap-flows exist.
06:52:19 <anil_rao> It seems like there is a bug somewhere because once I have a tap-service the list operation works as expected.
06:52:44 <reedip> the bug seems to be in Multi-node , because in single node, it is working
06:53:05 <anil_rao> Sure. I'll dig in to this some more to find out what is going wrong in the multi-node case.
06:53:28 <anil_rao> tap-flow-create didn't work initiallly because of missing --service parameter.
06:53:39 <reedip> anil_rao : the q-svc logs may be helpful ( and you can run neutron --debug tap-service-create)
06:53:55 <reedip> create -> list ^^^
06:54:04 <anil_rao> Nothing more than what I had sent you a couple of weeks back.
06:54:11 <reedip> anil_rao : ok
06:54:19 <anil_rao> I'll try the --debug option and check again tomorrow.
06:55:02 <vasubabu> anil_rao: i too found same issues
06:55:19 <vasubabu> i did add --service_id instead of --service
06:55:22 <anil_rao> I have made some minor corrections to the tap-flow-create logic and now got it work with --service. I'll provide the fix in my review comment on reedip's patch.
06:55:23 <vasubabu> it worked
06:55:43 <reedip> thats why I kept it on hold :)
06:56:25 <anil_rao> vasubabu: I'd prefer it that we call the parameter tap-service instead of service_id because reedip's implementation allows for both name and id.
06:56:36 <vasubabu> ok
06:56:46 <vnyyad> +1
06:56:53 <anil_rao> reedip: I'll have the review comments up in the gerrit review tomorrow. Sorry for the delay.
06:57:14 <reedip> anil_rao : sure, unless I find an easier method to get it working before that :D
06:57:49 <anil_rao> I had some other comments to ensure that the tap-flow and tap-service create operations are similar. At the moment they look quite different.
06:58:01 <anil_rao> Also, some comments on the help text. :-)
06:58:23 <anil_rao> If you can wait until I upload the comments tomorrow that would be great. :-)
06:58:51 <anil_rao> the show and delete commands are working correctly. No surprises there.
06:59:40 <reedip> ok :)
06:59:42 <anil_rao> I'll verify the operation of the taas driver next with actual traffic. Hopefully, everything is okay there.
07:00:45 <anil_rao> I am concerned about the arp anti-spoofing flows in br-int. For the Vancouver demo we had just shut that feature off by making the TaaS flows have higher priority. We'll need to solve this in an agreeable manner however.
07:01:30 <vnyyad> anil_rao: yeah that need to be resolved going forward
07:02:48 <anil_rao> there was a question today in the ml2 extensions review on this topic.
07:03:12 <anil_rao> did any of you see that?
07:03:52 <yamamoto> the one from Farhad?
07:04:03 <anil_rao> yamamoto: Yes
07:04:15 <yamamoto> #link https://review.openstack.org/#/c/267591/
07:05:52 <anil_rao> We essentially need an understanding between projects as to the order in which packets are exmined by their respective flows.
07:07:16 <soichi> anil_rao: agree
07:07:47 <anil_rao> I'll add something to that effect in that review and see what others have to say.
07:09:18 <anil_rao> Arp anti-spoofing is especially interesting because I see it as another form of security group checks (like anti mac and anti IP). today we sit below security groups, so technically we should be below arp anti-spoofing.
07:12:11 <vnyyad> +1
07:12:25 <yamamoto> anil_rao: makes sense
07:13:15 <anil_rao> I need to examine the data path for arp anti spoofing some more before I can comment more on this. I'll get to that as I test out the TaaS data path with actual traffic.
07:14:08 <anil_rao> soichi and kaz: Thanks a bunch for your work on the Horizon dashboard support for TaaS. I have some comments. Should I put them up on the mailing list?
07:14:26 <soichi> yes, please
07:14:46 <anil_rao> soichi: OK. I'll have them for you tomorrow. :-)
07:14:49 <reedip> Just a query : Is there any scope of getting the Spec approved for Mitaka for governance?
07:15:08 <reedip> reedip : sorry, just remembered Armando's comment
07:15:48 <reedip> seems I am pinging myself now.... need some coffee!
07:16:23 <anil_rao> :-)
07:16:52 <yamamoto> soichi: what's your LP/gerrit account?
07:17:47 <anil_rao> reedip: Do I need to do something special to get the 'neutron' command to work in a different machine than the DevStack controller node.
07:17:59 <anil_rao> reedip: with the taas extensions.
07:18:14 <soichi> yamamoto: i didn't have yet.
07:18:25 <reedip> anil_rao : my brain tells me no.
07:18:48 <reedip> Ideally if you have the TaaS extensions running, you shouldnt have any problems
07:19:10 <anil_rao> reedip: OK, thanks.
07:19:48 <soichi> topic: new core reviewers
07:19:57 <soichi> thank you for inviting me to the core team
07:20:10 <soichi> actually, i'm surprised that i was nominated as a core reviewer candidate
07:20:10 <vnyyad> your pleasure
07:20:17 <soichi> it is my pleasure to work for taas project
07:20:50 <reedip> +1
07:20:59 <anil_rao> +1
07:21:02 <kazu> +1
07:21:31 <anil_rao> +1 for yamamoto too.
07:21:50 <soichi> +1 for yamamoto
07:21:51 <vnyyad> +1
07:21:59 <yamamoto> soichi: feel free to reach me if you have anything unclear about gerrit.  in japanese if you prefer.
07:22:15 <soichi> yamamoto: thank you
07:22:34 <vnyyad> so should i go ahead and add them to the core reviewers in the project gerrit?
07:22:43 <yamamoto> thank you all
07:22:51 <yamamoto> vnyyad: we usually wait for a week or so
07:22:57 <vnyyad> sure :)
07:24:11 <soichi> i will create a gerrit acount
07:24:25 <reedip> +1
07:25:48 <vnyyad> aob+
07:25:52 <vnyyad> aob?
07:26:21 <yamamoto> ?
07:26:30 <vnyyad> any other  business :)
07:26:47 <reedip> naah , besides the times up
07:27:13 <yamamoto> nothing from me
07:27:27 <anil_rao> nothing from me too.
07:27:33 <soichi> me too
07:27:43 <kazu> i have no item
07:28:05 <vnyyad> thank everyone for the meeting today
07:28:15 <yamamoto> thank you
07:28:21 <vnyyad> see you in the next one
07:28:23 <soichi> bye
07:28:25 <anil_rao> thanks and bye
07:28:25 <kazu> bye
07:28:26 <vnyyad> bye all
07:28:29 <vasubabu> thanks you, bye
07:28:45 <vnyyad> #endmeeting