06:31:27 <anil_rao> #startmeeting taas
06:31:28 <openstack> Meeting started Wed Mar 30 06:31:27 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:31:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:31:32 <openstack> The meeting name has been set to 'taas'
06:31:35 <reedip> anil_rao : it syncs with me :D
06:31:54 <anil_rao> Hi
06:32:03 <soichi> hi
06:32:49 <anil_rao> #topic Summit planning schedule
06:33:47 <anil_rao> I see a topic in etherpad on OVS agent flow management for extensions
06:34:46 <anil_rao> I think this will be useful for us to discuss how different extensions can co-exist in OVS bridges with their respective flows
06:34:59 <reedip> anil_rao, yamamoto, fawadkhaliq : if you find a suitable option in the etherpad where we can take up TaaS use cases ( like the OVS bridge ) we can add our points on it as well
06:35:00 <anil_rao> Thoughts?
06:35:18 <reedip> correction : OVS agent ...
06:35:50 <reedip> #link : https://etherpad.openstack.org/p/newton-neutron-summit-ideas
06:36:23 <anil_rao> reedip: I mentioned one just above...
06:36:24 <reedip> this link is basically for ideas of design sessions from Teusday to Thursday
06:37:04 <reedip> anil_rao : I may be fast, my system is slow .. it sent it after your message..... :)
06:37:46 <anil_rao> reedip: :-)
06:38:14 <anil_rao> I think we could join in that OVS extensions discussion. There will be others too (other extensions) so this might be a good session for us
06:38:28 <reedip> anil_rao : +1
06:38:35 <yamamoto> anil_rao: +1
06:38:45 <kaz> :1
06:38:51 <soichi> +1
06:38:51 <kaz> +1
06:39:09 <anil_rao> Should we also add a separate line item for TaaS?
06:41:07 <anil_rao> Anything else on this topic?
06:41:16 <soichi> anil_rao: i think it is good idea for advatising TaaS
06:41:52 <soichi> advatising -> advertising
06:42:48 <reedip> anil_rao: we can mention it, it can be combined with other *aaS items for a single session
06:43:03 <anil_rao> reedip: Sounds good.
06:43:08 <reedip> depending on the number of sessions alloted
06:44:09 <soichi> reedip: +1
06:44:36 <anil_rao> OK, let move to the next topic
06:44:46 <anil_rao> #topic Async Calls
06:45:10 <anil_rao> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090088.html
06:45:42 <anil_rao> What do folks think about this?
06:47:56 <reedip> anil_rao: Yee....
06:48:14 <reedip> already gave my opinion on the ML btw ..
06:48:38 <anil_rao> reedip: Yes, I saw that. Thanks. Just wanted to hear from the others too.
06:48:45 <yamamoto> +1 from me
06:49:03 <yamamoto> i guess everyone agree it's a good idea.  a question is when to do it.
06:49:11 <soichi> anil_rao: i agree to provide async calls
06:49:39 <kaz> +1
06:49:53 <anil_rao> yamamoto: Perhaps we should do this after the Summit. If we are going to do a demo then we don't want too much code churn now.
06:50:29 <soichi> anil_rao: agree
06:50:45 <reedip> anil_rao : This information should be mentioned as a part of "Future Improvements" in the presentation in Austin
06:51:00 <reedip> along with the nitty gritty already mentioned in the spec
06:51:11 <anil_rao> reedip: +1
06:52:26 <yamamoto> probably we can just add a placeholder "status" field which is always ACTIVE for now?
06:52:54 <anil_rao> yamamoto: I like this idea.
06:52:56 <reedip> yamamoto : so basically a working code for the front end and the backend implementation on hold ???
06:53:18 <reedip> that should not be too much of a problem
06:54:42 <yamamoto> we can say that the status always being ACTIVE is a problem in the specific implementation. :-)
06:56:07 <anil_rao> We need async calls for everthing that eventually makes its way to the backend. I.e. create, update and delete.
06:56:30 <yamamoto> anil_rao: +1
06:57:36 <soichi> +1
06:57:45 <kaz> +1
06:58:18 <anil_rao> OK, looks like everyone is in agreement. We'll move to the next topic.
06:58:33 <anil_rao> #topic TaaS Dashboard Discussion
06:58:52 <soichi> i guess newly added "tap service tab" can be merged to Liberty without problems
06:58:57 <anil_rao> #link https://review.openstack.org/#/c/295735/2
06:59:03 <soichi> excuse us that we didn't test yet, because last week and this week we are busy on other stuff
06:59:11 <soichi> (our fiscal year starts in April and ends in March)
06:59:25 <reedip> soichi: everyone's does.... :(
06:59:39 <soichi> on the other hand, i guess some effort will be required to merge our changes on "network topology tab" to Liberty
07:00:17 <anil_rao> soichi: Here is a question for kaz and you.
07:00:26 <soichi> yes
07:00:46 <anil_rao> How is the cloud admin supposed to work with the UI?
07:01:46 <kaz> we suposed to use normal (non admin) user.
07:02:36 <anil_rao> Since the cloud admin doesn't see the topology view, I think having both tap-service and  tap-flow workflows in the tap-service tab would be nice.
07:02:58 <anil_rao> What do you think?
07:04:03 <kaz> I think so.
07:05:05 <anil_rao> soichi, kaz: I'll add comments  to the review.
07:05:18 <kaz> yes
07:07:44 <anil_rao> kaz: Can I test this via devstack?
07:09:15 <kaz> You can test with the kilo horizon.
07:09:21 <kaz> by devstack
07:09:56 <kaz> I will send a mail how to test via.
07:10:03 <kaz> devstack .
07:10:11 <anil_rao> kaz: Thanks!
07:10:49 <anil_rao> We'll move to the next topic then
07:11:02 <anil_rao> #topic Spec Discussion Completion
07:11:04 <reedip> @anil_rao : Spec continuation can be done on the ML. I guess you had some comments which you wanted to give on my questions, but missed out last week . Also my #action need to revisit the taas Spec
07:11:16 <anil_rao> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/088645.html
07:12:00 <anil_rao> reedip: Yes, sorry about that. I was out of town for a few days last week. I'll get that done in the next few days.
07:12:35 <reedip> anil_rao : yeah sure, the ML would be the best way to sort out the spec for now...
07:12:57 <reedip> as it may take some time , and we have sufficient to discuss in the current hour
07:16:54 <anil_rao> #topic Migration of TaaS to OSC
07:17:31 <reedip> anil_rao : well, now that openstack client is in the picutre, and it is integrating a lot of clients into it
07:17:49 <reedip> anil_rao: neutron client amongst them as well
07:18:37 <reedip> anil_rao : I think it should be logical to have TaaS set up with openstack client as well, so that we have support there. It would incorporated as a plugin, much like how neutronclient has been setup
07:19:52 <anil_rao> reedip: Does all Neutron functionality go together or do separate projects (such as TaaS) do the migration themselves.
07:20:37 <anil_rao> I mean if neutron client is integrated into OSC does TaaS get into OSC automatically
07:20:51 <reedip> core neutron functionality  in neutronclient will go to openstack SDK
07:21:07 <anil_rao> ok
07:21:13 <reedip> FWaaS, LBaaS and other *aaS related components will have plugins
07:22:24 <anil_rao> reedip: With neutron client get depreciated eventually?
07:23:09 <reedip> anil_rao : not yet, for the users who would not use openstackclient, neutronclient would still exist...  the final decision on that would take some releases ( maybe by Q/R release)
07:23:54 <anil_rao> If projects are migrating to openstackclient then it makes sense for TaaS to do so too.
07:24:09 <reedip> anil_rao : yup, thats why I mentioned it :)
07:24:34 <reedip> having a ready support in N-release would atleast not require us any future modifications
07:25:01 <anil_rao> reedip: Agree
07:25:28 <anil_rao> Lets move to open discussion
07:25:35 <anil_rao> #topic Open Discussion
07:26:45 <soichi> i have no additional topic for today
07:27:06 <yamamoto> i have a quick question about api
07:27:14 <anil_rao> Yes
07:27:16 <yamamoto> is it supposed to allow duplicated tap-flows?
07:27:52 <anil_rao> yamamoto: Are you refering to one port (vNIC) assigned to multiple tap-service instances
07:28:28 <yamamoto> yes, and even with the same tap-service
07:29:08 <yamamoto> the reference impl doesn't seem to deal with either cases, right?
07:29:22 <yamamoto> https://bugs.launchpad.net/tap-as-a-service/+bug/1562769
07:29:22 <openstack> Launchpad bug 1562769 in tap-as-a-service "multiple tap-flows on the same source-port seem broken" [Undecided,New]
07:29:36 <anil_rao> I see a tap flow as a mapping from a port to a tap-service instance.
07:30:03 <yamamoto> my question is how it's supposed to be in api level.  (i'm considering midonet impl)
07:30:32 <anil_rao> I did think about us possibly allowing a port to be assigned to more than one tap service instance. Each such association between the port and a tap service instance would be one unique tap flow.
07:31:13 <anil_rao> I do not quite follow the need for multiple associtations (flows) between a single source port and a tap service instance.
07:31:59 <yamamoto> neither do i.  just wondering if there are use cases.
07:32:12 <anil_rao> We are out of time. Let us discuss this next week.
07:32:20 <yamamoto> sure thank you
07:32:26 <soichi> bye
07:32:28 <kaz> bye
07:32:32 <yamamoto> bye
07:32:34 <anil_rao> Bye
07:32:40 <anil_rao> #endmeeting