06:30:08 <anil_rao> #startmeeting taas
06:30:09 <openstack> Meeting started Wed Mar 16 06:30:08 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:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
06:30:12 <openstack> The meeting name has been set to 'taas'
06:30:23 <anil_rao> Hi
06:30:25 <kaz> hi
06:30:26 <soichi> hi
06:31:10 <anil_rao> soichi: Can you kindly send the email address you registered with OpenStack. We need to give you core permissions.
06:31:13 <yamamoto_> hi
06:31:36 <irenab> hi
06:31:50 <soichi> anil_rao: okay, i will send my e-mail address to you
06:31:50 <reedip> hi
06:32:00 <anil_rao> soichi: Thanks.
06:32:25 <anil_rao> Let's get started
06:32:35 <anil_rao> #topic: Spec Discussion
06:32:56 <reedip> irenab posted some comments to the questions which I shared
06:33:00 <reedip> for the spec
06:33:05 <anil_rao> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/088645.html
06:34:04 <fawadkhaliq> hello guys!
06:34:06 <anil_rao> reedip: Sorry for being a little bit behind. I'll add some thoughts to that email thread soon.
06:34:18 <reedip> anil_rao: sure .. fawadkhaliq: hi
06:34:42 <anil_rao> There was one question that I was curious about.
06:35:03 <reedip> so irenab gave her comments on #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/089207.html , and she is here today for the discussion, so any concerns from her end can be closed early on
06:35:13 <anil_rao> Is there anything in the current API definition that is OVS dependent?
06:35:13 <reedip> anil_rao : shoot ...
06:35:38 <anil_rao> I can't think of what that might be
06:36:09 <irenab> reedip: I gues maybe it was for limiting the spec to what only possible with OVS
06:36:38 <reedip> anil_rao : not in the API, but as discussed in some of the earlier meeting logs, we need to split the implementation to allow other vendors like bigswitch and other third party to create thier own versions ( yamamoto_ : I am reading up the ml2 spec, maybe it would help here )
06:37:15 <reedip> irenab : maybe we can let the API stay , but in the Release notes, mention the limitation to OVS
06:37:16 <reedip> ?
06:37:34 <irenab> reedip: sounds good
06:37:51 <reedip> anil_rao : any suggestions ?
06:38:22 <anil_rao> The current implementation is just a reference implementation. I don't see any reason why other backends cannot be implemented by interested parties.
06:39:50 <reedip> anil_rao : you are right.... it is a reference implementation. But when we share the code for review with other neutron reviewers, let make this aspect clear...  ( that this is a reference implementation) , else we might be subjected to a pretty grilling review
06:40:17 <reedip> anil_rao: thats my point of view ( maybe I could be wrong )
06:40:51 <anil_rao> By reference implementation I meant that it is one implementation, which we expect will work in production deployments. So a grilling review is fair game.
06:41:29 <anil_rao> I also agree that we can make the implementation more friendly to other variants.
06:41:48 <reedip> anil_rao: yes , but for this release, we can limit the scope, and let it expand in the future
06:42:03 <anil_rao> reedip: Agree
06:42:19 <reedip> that would definitely require rework in the future, but allow us to provide a working software
06:42:25 <reedip> in the demo in Austin
06:42:39 <irenab> reedip: As long as the layering is good and API/Plugin are backend agnostic, this should be ok. but maybe its beyond the spec which in my opinion should focus on generic stuff
06:42:49 <yamamoto_> vlan_range_start config seems a little implementation specific.
06:43:25 <fawadkhaliq> yamamoto_: +1
06:43:38 <anil_rao> yamamoto_: I agree about that. I would consider that more implementation dependent than a portion of the API spec.
06:44:26 <reedip> irenab : yes, API may not require this information... however, this was one of the points which I observed cross-referencing different links, so thought of putting it up in the discussion, maybe it should have been a separate point
06:44:55 <anil_rao> Also, vlan_range is a stop gap measure until the community comes to an agreement on how to share resources in OVS.
06:45:23 <anil_rao> Apparently the ML2 driver extensions work does not address this crucial issue
06:45:33 <yamamoto_> maybe those options can be moved into a separate group eg. [taas_ovs]
06:46:07 <anil_rao> yammamoto_: That should be fine.
06:46:38 <reedip> yamamoto_ +1
06:46:45 <anil_rao> I am still worried though on how different projects plan to simultaneously work with OVS flows at the same time.
06:46:55 <anil_rao> Not sure where to bring this up?
06:47:00 <anil_rao> Any thoughts?
06:48:01 <reedip> ML , and Austin summit
06:48:28 <yamamoto_> i guess ML is best for the topic
06:48:33 <reedip> we should actually have a discussion with all the neutron core ... this may be a good point for discussion
06:48:51 <anil_rao> reedip,yamamoto_: ok
06:49:50 <anil_rao> Let's move to the next topic, if that's okay.
06:51:07 <anil_rao> #topic Spec Discussion
06:51:28 <anil_rao> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/089330.html
06:51:43 <anil_rao> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/089446.html
06:52:03 <soichi> anil_rao: thank you for your comments
06:52:34 <anil_rao> soichi: You are welcome. The TaaS UI looks very nice. :-)
06:53:18 <soichi> i'm preparing to share source code
06:53:27 <anil_rao> soichi: Awesome!
06:53:43 <anil_rao> soichi: I have a few questions on your reply.
06:53:50 <soichi> yes
06:55:09 <anil_rao> I wasn't sure about the part where you mentioned there being a lot of ports being shown. Can you kindly explain?
06:55:57 <soichi> if an instance is selected by user, we can list ports associated with the instance
06:56:16 <soichi> otherwise all ports can be a candidate
06:56:49 <anil_rao> soichi: Ok, I got it.
06:57:27 <anil_rao> Wouldn't the same be the case for the tap-service-create operation though.
06:57:59 <anil_rao> we do allow the the user to specify the (destination) port for the tap-service-create call
06:58:26 <soichi> anil_rao: yes, I think so
06:59:16 <soichi> i guess destination port should be created with a name
06:59:50 <soichi> then, a uesr can select an appropriate port by seeing name
07:00:04 <anil_rao> soichi: Let me think about this some more. If I have a better idea I'll add to the email thread.
07:00:21 <soichi> yes, thank you
07:01:26 <anil_rao> There is an aspect of the API that still bothers me. Let me try to explain.
07:01:38 <reedip> ??
07:02:58 <anil_rao> The current API only returns a failure due to some prelimiary checks carried out by the TaaS plugin. After the control is dispatched to the TaaS agent/driver, we have not mechanism of notifying the front-end that a call failed.
07:03:35 <anil_rao> I think we need to fix this, otherwise we will end up in a situation where the front-end thinks that a tap-service/tap-flow is correctly instantiated when it might not acutally be the case.
07:04:09 <anil_rao> My suggestion is to add the concept of a status field, similar to other OpenStack operations.
07:04:33 <anil_rao> This status could be in-progress, succeed or failed.
07:04:55 <reedip> anil_rao : similar to what has already been done in LBaaS
07:05:00 <anil_rao> It will also help in the situations where the backend logic takes a while to complete a call.
07:05:25 <anil_rao> reedip: Yes. Actually many OpenStack projects work in this fashion.
07:05:32 <reedip> like Start -> Pending-Create -> Failure or Start -> Pending-Create -> Success
07:05:54 <anil_rao> Yes, something like that. :-)
07:06:19 <reedip> anil_rao : actually this is a pretty common design pattern ... we can ( and from what you said we should) implement it
07:06:19 <anil_rao> This will affect the UI work that Soichi and Kaz are doing too.
07:06:47 <anil_rao> reedip: Agree
07:07:24 <yamamoto_> +1 for having status
07:07:31 <anil_rao> Let me write up a description on the ML and also submit a bug .
07:07:39 <soichi> +1
07:07:45 <kaz> reedip: +1
07:08:10 <reedip> anil_rao: you have now 3 emails for ML :)
07:08:54 <anil_rao> Yes, I will be on it tomorrow morning. After the time change here (daylight savings) its now midnight. :-(
07:11:25 <anil_rao> Any other thoughts on the TaaS Dashboard work?
07:12:48 <anil_rao> ok, next topic then.
07:13:02 <anil_rao> #topic Discussion over Summit presentation
07:13:36 <reedip> So I wanted to know how and when we could meet up
07:13:44 <reedip> how to proceed with the presentation
07:13:44 <anil_rao> Here are some thoughts.
07:13:52 <reedip> what matter would we present
07:14:24 <anil_rao> We can set up a WebEx session next week (on Fawad's request) to discuss this.
07:14:38 <anil_rao> Fawad will be preparing a template.
07:14:41 <fawadkhaliq> anil_rao: yes, let's do it
07:14:56 <anil_rao> We should essentially cover the things we mentioned in the abstract of the proposal.
07:15:21 <fawadkhaliq> anil_rao: reedip I will come up with template, that we can all fill in and divide
07:15:28 <fawadkhaliq> anil_rao: +!
07:15:33 <fawadkhaliq> anil_rao: +1
07:15:38 <anil_rao> I will also share some thoughts on the demo. Please feel free to debate and discuss
07:15:52 <reedip> anil_rao: sounds like a plan
07:16:21 <anil_rao> I am putting together a new DevStack env with all of the latest code changes (there have been quite a few recently). :)
07:16:29 <reedip> anil_rao : Honest Request ... please keep the session on a day when there is no T20 match for India :D
07:16:52 <fawadkhaliq> reedip: lol
07:17:01 <pgadiya> reedip: lol :)
07:17:14 <reedip> :D
07:17:15 <anil_rao> Sure. :-)
07:17:19 <reedip> thanks
07:18:05 <anil_rao> I think it will be nice to incorporate both the Neutron client and the TaaS UI in the demo to show progress over the past Tech Talk.
07:19:09 <soichi> anil_rao: i agree
07:19:13 <reedip> anil_rao : +1
07:20:12 <anil_rao> Next topics:
07:20:32 <anil_rao> #topic Announcement: New Core Reviewers
07:21:20 <anil_rao> Based on all the +ve votes received yamamoto_ and soichi are our new core reviewers.
07:22:33 <yamamoto_> thank you
07:22:47 <soichi> thank you
07:23:03 <reedip> +1
07:23:09 <kaz> +1
07:23:15 <reedip> sorry, now you guys would give  +2 :D
07:23:54 <anil_rao> #topic Study up ML2 extension
07:23:58 <fawadkhaliq> congrats yamamoto_ soichi
07:24:03 <fawadkhaliq> :)
07:24:45 <reedip> yeah, I have started to study the extension implementation, have some confusions. I would ask yamamoto_ and fawadkhaliq once I read it a bit more
07:25:24 <reedip> it was mentioned basically as a progress report
07:25:50 <anil_rao> That's good.
07:26:11 <anil_rao> #topic Issue observed for empty tap-service/tap-flow listing
07:26:31 <anil_rao> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/088454.html
07:26:54 <anil_rao> reedip: I belive this is now closed.
07:27:04 <reedip> anil_rao : yup
07:27:27 <reedip> I think soichi carried it forward while editing the agenda for today, and I forgot to remove it
07:27:35 <anil_rao> Looks like we covered all of the agenda items today. :-)
07:27:48 <anil_rao> Any other open issues for discussion. We have a couple of minutes
07:27:50 <soichi> oh, excuse me
07:28:04 <anil_rao> soichi: Yes
07:28:56 <soichi> just copy and paste last week agenda
07:29:22 <reedip> soichi : I guessed so, no issues, I also forgot :)
07:29:37 <soichi> :)
07:30:34 <anil_rao> OK, time's up.
07:30:41 <anil_rao> #endmeeting