06:30:55 <vnyyad> #startmeeting taas
06:30:56 <openstack> Meeting started Wed Dec  2 06:30:55 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:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:30:59 <openstack> The meeting name has been set to 'taas'
06:31:05 <soichi> Hi
06:31:11 <vnyyad> hi
06:31:11 <Kazu> Hello
06:32:26 <trinaths> hi
06:32:45 <vnyyad> #topic finish usecase and API discussion
06:32:48 <reedip> Hi
06:34:08 <reedip> I raised a query related to the API discussion
06:34:11 <reedip> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080449.html
06:35:00 <reedip> If there is time today ( or if it can be taken in the current discussion for API), then please let me know
06:35:19 <anil_rao> reedip: I looked at your email. Sorry for not being able to respond sooner.
06:35:30 <anil_rao> We can discuss this as our first item.
06:36:36 <anil_rao> reedip: In your first point you are suggesting removing 'taas' from the endpoint string?
06:37:42 <reedip> anil_rao : yes , if it is possible
06:38:29 <reedip> I checked the neutron-client repo , as all the end points are mentioned there and found that most ( if not all) extensions of neutron are directly refferred from v2_0
06:38:49 <anil_rao> I am okay if doing so makes us more compatible with existing convention? What do others have to say?
06:39:03 <vnyyad> anil, reedip: i guess we can take a look at it to keep parity with other services
06:39:33 <vnyyad> any comments from others?
06:42:00 <anil_rao> reedi: for the 2nd point in your email, I agree that we can change source_port to port. Do you want to go with 'port' or 'port_id?
06:42:30 <reedip> I would prefer port, because in all the other neutron CLIs, we use port itself.
06:42:39 <reedip> Also it allows us to have Port ID or Port Name
06:42:44 <reedip> so if a user has named a port
06:42:44 <anil_rao> reedip: okay
06:43:11 <reedip> then he can use the port name, instead of him listing the port and then copying the ID ( which in itself is a manual task for now)
06:43:58 <anil_rao> Sure
06:44:09 <vnyyad> reedip: is the uniqueness of the port name ensured?
06:44:35 <reedip> vnyyad : No, but the way neutronclient ( and in the future, I hope Openstackclient) searches is
06:44:46 <reedip> a) whatever is passed is first searched by ID
06:44:52 <reedip> if ID is found then use that
06:44:57 <reedip> if not then
06:45:07 <reedip> b) search the same by name
06:45:31 <reedip> if number of elements found by name = 0 , then there is no element( in our case no port)
06:45:52 <reedip> if no. of element is 1, then the element( port in our case) would be forwarded in the API call
06:46:31 <reedip> if no. of element > 1, then it would state that there are multiple instances, and result in an error. This is the common function observed in all the neutron CLIs
06:47:15 <vnyyad> reedip: thanx for the clarification
06:47:47 <reedip> okay, so we agree that source_port and port_id can be changed to 'port'
06:48:06 <anil_rao> Sounds good to me.
06:48:08 <reedip> and for moving the elements under v2_0/taas to v2_0, a further discussion may be necessary
06:49:08 <soichi> +1
06:49:11 <reedip> anil_rao, vnyyad : Okay then, I will move the source_port and port_id to port ( filing a bug for the same , for tracking purpose)
06:49:43 <vnyyad> reedip: +1
06:49:51 <anil_rao> +1
06:49:54 <Kazu> reedip: agree
06:50:53 <reedip> okay thanks :)
06:51:04 <anil_rao> Let's move to the next topic. -- subproject spec
06:51:31 <vnyyad> #topic subproject spec
06:52:39 <anil_rao> Do folks feel that we need a new spec?
06:53:49 <reedip> anil_rao : Yes, I think Fawad also wanted this to be taken up .
06:54:56 <reedip> having a spec would allow for easier tracking of changes and would make TaaS an entity of the Neutron Governance
06:55:01 <reedip> ( IMO)
06:55:31 <anil_rao> We have a spec. I was wondering what folks think about reactivating it or creating a new one.
06:56:54 <reedip> Reactivating would avoid extra rework (??)
06:57:06 <anil_rao> Since it is quiet here, let's discuss this topic on the mailing list, as responses to Fawad's thread.
06:57:29 <reedip> Yup, other members of Neutron Family can also chip in
06:57:37 <reedip> at the ML
06:58:17 <anil_rao> OK.
06:59:03 <anil_rao> Moving to next topic?
06:59:54 <vnyyad> #topic creating dashboard repository for neutron subprojects
07:00:03 <soichi> yes, i added this item.
07:00:19 <soichi> amotoki proposed several possible options about dashboard repository for neutron subprojects.
07:00:30 <soichi> i think it is a good idea to have a dashboard repository for taas.
07:00:44 <soichi> it makes easy to submit and share souce code.
07:01:04 <soichi> currently, i guess (c) is the best choice.
07:01:17 <soichi> if you agree, would you kindly reply +1 for amotoki's proposal?
07:01:27 <reedip> soichi: link?
07:01:32 <reedip> or is it in the agenda?
07:02:07 <soichi> yes, link is in the agenda
07:02:23 <soichi> link: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080441.html
07:02:42 <reedip> Oh ok , thanks :)
07:02:42 <amotoki> I just raised options for repos of dashboard implemetations. neutron community folks prefer to having dashboard repo in each repo.
07:03:21 <amotoki> I haven't sent a reply mail, but I think there are some challenges which need to be addressed by neturon subprojects.
07:03:21 <reedip> amotoki: option(d) ?
07:03:27 <amotoki> option(c)
07:03:44 <reedip> Ohk
07:03:52 <anil_rao> I am not clear about the difference between (c) and (d)
07:04:02 <amotoki> horizon community does not have an experience of sharing dashboard and server project in a same repo.
07:04:49 <amotoki> perhaps it can, but we need to explore a common way on how to organize dashboard directory in its own neutorn subproject repo.
07:06:06 <amotoki> option (c) means networking-foo/dashboard
07:06:17 <amotoki> option (d) means networking-foo-dashboard repository
07:06:40 <amotoki> anil_rao: is it clear now?
07:06:51 <anil_rao> amotoki: Yes, Thanks.
07:07:05 <yamamoto> soichi: is your horizon support currently implemented as option (a) ?
07:07:31 <soichi> yes
07:08:21 <anil_rao> What to the Horizon folks recommend? How are other Neutron subprojects dealing with this?
07:08:28 <amotoki> I finally get time to write a reply mail. you will see it soon. I could not find time last week at all due to my family affairs.
07:09:49 <anil_rao> amotoki: Thanks
07:10:13 <amotoki> anil_rao: not decided. I wil request david horizon ptl to follow it up again.
07:12:29 <anil_rao> soichi: Any thoughts on the few items I mentioned in my review of your proposed UI for TaaS?
07:13:30 <soichi> I agree your comments. all TaaS API options should be supported.
07:14:27 <anil_rao> Let's move to the next topic
07:14:39 <soichi> Yes
07:14:55 <soichi> link: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080761.html
07:14:55 <anil_rao> #topic port security setting
07:15:10 <vnyyad> #topic port security setting
07:15:34 <soichi> this is just an announcement that i submitted a discussion about port security setting to the mailing list.
07:15:44 <soichi> i would appreciate if you reply your comments.
07:16:04 <anil_rao> soichi: Will do? Here is a quick question though
07:16:11 <soichi> yes
07:16:31 <anil_rao> soichi: Are you seeing this when you have the monitoring VM attached to br-tap (instead of br-int)?
07:17:17 <soichi> No. monitoring VM is connected to br_int. The original implementation of TaaS.
07:18:08 <vnyyad> anil: we could try to reproduce this
07:18:28 <anil_rao> Sure.
07:19:06 <soichi> I will wait your reply.
07:21:04 <vnyyad> any other topic to be discussed
07:22:12 <yamamoto> i have a question
07:22:49 <anil_rao> yamamoto: Yes
07:22:58 <yamamoto> is there any specific reasons why mac learning is disabled by our agent?  ie. do you see any problems if learning is unconditionally disabled in the hybrid interface driver?
07:24:25 <anil_rao> We disabled mac learning in the Linux bridge (that connects the OVS port on br-int to the VM's vNIC) otherwise, mirrored traffic could never make it to the monitoring VM.
07:24:47 <anil_rao> If there is a cleaner way to overcome this issue, I am all for it.
07:25:01 <yamamoto> yes, i understand why it should be disabled.  my question is why taas agent should do it.
07:25:55 <anil_rao> We don't need to do it from the TaaS agent if there is another way to achieve the same.
07:26:16 <yamamoto> put it in the other way, do you know anything relying on the mac learning in the per-vif bridge?
07:26:45 <yamamoto> i want to make it unconditional.
07:27:29 <anil_rao> From what I see, mac learning avoids the need to flood the bridge. Since there are only two ports in that per-vNIC bridge this flooding is not a large overhead but to some it might be.
07:28:09 <vnyyad> anil_rao: i guess we did discuss this
07:28:56 <vnyyad> in a 2 port bridge how much different is flooding from learning in terms of performance
07:29:50 <anil_rao> There is one unused port (which is the internal port of the Linux bridge). So flooding will end up sending copies of the packet both to the VM's vNIC as well as to the bridge's internal port.
07:30:24 <vnyyad> can we take this in the mailing list
07:30:34 <vnyyad> i guess we ran out of time
07:30:36 <yamamoto> my impression is we should either a) make it uncodintional or b) make taas agent restore the setting
07:31:13 <vnyyad> yamamoto: +1 taas agent should restore the setting
07:31:23 <Kazu> agree
07:31:34 <anil_rao> +1 on (b).
07:31:58 <anil_rao> We are out of time. :)
07:32:24 <vnyyad> see you all next week and/or in the meeting list
07:32:32 <soichi> thank you, bye
07:32:32 <vnyyad> bye
07:32:32 <yamamoto> bye
07:32:35 <anil_rao> bye
07:32:36 <Kazu> bye
07:32:46 <vnyyad> #endmeeting