05:30:37 <anil_rao> #startmeeting taas
05:30:38 <openstack> Meeting started Wed Jun 22 05:30:37 2016 UTC and is due to finish in 60 minutes.  The chair is anil_rao. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:30:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:30:42 <openstack> The meeting name has been set to 'taas'
05:30:44 <yamamot__> hi
05:30:46 <soichi> hi
05:30:48 <kaz> hi
05:30:54 <anil_rao> Hi
05:31:00 <soichi> anil_rao: how are you?
05:31:18 <anil_rao> Was down with the flu for the past few weeks. Feeling better now.
05:31:44 <soichi> sounds good
05:32:02 <anil_rao> Thx. Need to catch up on things  that I have missed. :-)
05:32:52 <anil_rao> #topic do we still aim to make a release compatible with mitaka?
05:33:14 <anil_rao> #link http://lists.openstack.org/pipermail/openstack-dev/2016-June/097727.html
05:33:24 <vnyyad> hi all
05:33:43 <anil_rao> Hi
05:35:23 <yamamot__> given our recent pace of development, i guess it's difficult to make a release for mitaka.  how do you think
05:36:01 <soichi> yamamot_: i agree with you.
05:36:26 <vnyyad> yamamot_ i agree too
05:36:42 <anil_rao> yamamot__: So we essentially need to move to the Service Plugin model?
05:37:01 <yamamot__> ?
05:37:07 <yamamot__> we already have a service plugin
05:37:30 <yamamot__> are you talking about https://review.openstack.org/#/c/307708/ ?
05:37:32 <vnyyad> yes
05:37:38 <anil_rao> Yes.
05:38:37 <yamamot__> well, i can't say "we".  but for some of us (especially vendors) it's benefitical to make the plugin use backend-specific service drivers.
05:39:38 <yamamot__> the patch implements it.   "vendor" part of that is https://review.openstack.org/#/c/320871/ (midonet)
05:41:36 <yamamot__> i guess the commit line of the patch ("Support service framework to separate plugin logic") is a bit cryptic. :-)
05:41:52 <anil_rao> yamamot__: I haven't checked that review as yet (apologies). How does it fit in with the existing reference implementation?
05:42:36 <yamamot__> (most of) the reference implementation specific part of the plugin has been moved into its own service driver.
05:42:58 <yamamot__> and the driver is used by default.
05:43:38 <anil_rao> yamamot__: Thanks. I'll look into this review.
05:44:10 <yamamot__> anil_rao: thank you
05:45:30 <anil_rao> Any other opinions on this topic?
05:45:46 <vnyyad> yamamot_, anil: will review too
05:45:53 <yamamot__> vnyyad: thank you
05:45:55 <reedip> hi
05:46:39 <yamamot__> reedip: hi
05:47:12 <anil_rao> reedip: Hi
05:47:31 <vnyyad> reedip: hi
05:47:35 <yamamot__> wrt review, let me announce review inbox again
05:47:47 <yamamot__> #link https://goo.gl/DdeEy8 TaaS review inbox
05:49:03 <yamamot__> i recommend everyone here to bookmark it. :-)
05:49:24 <anil_rao> yamamot__: I must have missed the previous announcement but this is very nice! Thanks
05:49:26 <soichi> i will
05:49:50 <vnyyad> done
05:50:20 <soichi> done :)
05:50:24 <kaz> i did too
05:50:26 <anil_rao> yamamot__: Looks like the page contents shunk quite a bit in the last 20 minutes. :)
05:52:12 <yamamot__> anil_rao: ?
05:53:20 <anil_rao> yamamot__: Just before the TaaS meeting started the contents of that page filled a whole page on my browser; now it is only half a page in length.
05:54:13 <yamamot__> which page?
05:54:55 <anil_rao> The review inbox page.
05:55:10 <yamamot__> i guess you reviewed some of them?
05:55:24 <yamamot__> it doesn't show patches you already voted
05:55:40 <anil_rao> OK, I suppose they have been removed. :-)
05:55:51 <yamamot__> for me the page is empty :-)
05:57:28 <anil_rao> #topic gate blocker
05:57:41 <anil_rao> #link https://review.openstack.org/#/c/326231/
05:57:57 <yamamot__> anil_rao: i guess you are looking at last week's agenda
05:58:13 <anil_rao> Sorry. Wrong cut and paste. Let me update
05:58:41 <anil_rao> #topic State transition model for TaaS objects (Service, Flow)
05:59:19 <vnyyad> uploaded a new diagram based on the feedback
05:59:51 <vnyyad> https://wiki.openstack.org/w/images/8/8a/Status_Flow_Chart.png
06:01:30 <yamamot__> i suppose agent-level bind can bring "Port Unbound" to "Active" right?
06:02:13 <vnyyad> true... i missed representing it...
06:03:05 <soichi> kaz is planning to set "INACTIVE" as default (initial) status in DB
06:03:06 <anil_rao> vnyyad: Didn't quite follow the unbound and bound state. Is this when the port is not bound to a host?
06:04:08 <vnyyad> anil_rao: this is a case when the port on which tap service or flow as originally associated but the port went missing
06:06:01 <anil_rao> How do we bind it again
06:07:32 <vnyyad> anil_rao: i did not get it
06:08:38 <yamamot__> a port can be unbound in the first place (eg. just neutron port-create)   it can be bound later (eg. launch a VM with the port)
06:08:50 <anil_rao> vnyyad: yamamot__ said above that perhaps agent-level bind can bring "Port Unbound" to "Active".
06:09:20 <anil_rao> yamamot__: That is why I was under the impression that we are talking about the host binding of a port
06:10:59 <yamamot__> i personally think it isn't worth to have "Port Unbound" state at all. if a user want to know the state, he can look at the neutron port. but probably it's just me.
06:13:07 <anil_rao> yamamot__: In the reference implementation we have tap-service (destination side) related flows added on the host to which the dest port is bound.
06:14:00 <anil_rao> If the port is not bound we cannot put down these flows. Also if the destination port, for some reason, is no longer bound (e.g. VM attached to it is gone) we have to clean out those flows.
06:14:08 <vnyyad> anil_rao: we add it only when the port gets bound, ie when the VM is created
06:15:04 <anil_rao> vnyyad: Yes, that is correct. We will need some way to find out when the port is bound though.
06:15:36 <vnyyad> anil_rao: and also when it goes missing from the host
06:15:59 <anil_rao> vnyyad: Yes.
06:16:46 <yamamot__> i suppose it can be done at some port event callbacks in l2 agent
06:17:04 <vnyyad> yamamto_: yes
06:17:16 <yamamot__> assuming we make our agent to l2 agent extension
06:18:11 <yamamot__> a question is if we want/need to make it known to the taas plugin
06:18:11 <vnyyad> yamamot_: needs to be explored
06:18:46 <yamamot__> reedip: do you have any opinion?
06:22:02 <vnyyad> lets put this on the agenda next week to discuss
06:22:10 <soichi> +1
06:22:26 <anil_rao> +1
06:22:27 <yamamot__> i guess we need to make agent side concrete before this fsm
06:22:58 <vnyyad> yes, sounds good
06:24:12 <soichi> i'd like to discusss about TaaS session (presentation) in Barcelona Summit
06:24:20 <soichi> the submission deadline is 13th June
06:24:26 <soichi> kaz or soichi would like to join as a speaker
06:24:35 <soichi> what do you say to make a presentation about our progress (e.g. asynchrous API etc.)?
06:24:41 <soichi> and performance benchmark, if possible
06:25:01 <yamamot__> July 13 i guess
06:25:04 <anil_rao> soichi: I think a performance study would be most appropriate
06:25:06 <soichi> yes
06:25:34 <anil_rao> We can do a detailed analysis of the behavior too
06:25:42 <soichi> yamamoto__: yes
06:26:50 <soichi> anil_rao: sounds great
06:27:29 <anil_rao> soichi: I will be examining the perf results Kaz and you posted a few weeks back. I'll get back to the group on this in a couple of days.
06:27:57 <anil_rao> I have a hardware multi-node setup coming up shortly. I'll run some experiments from my side too and share the results.
06:28:28 <soichi> okay, thank you
06:28:33 <vnyyad> thanks anil
06:30:26 <anil_rao> Looks like we are out of time. See you all next week.
06:30:31 <anil_rao> #endmeeting