05:33:19 <yamamoto> #startmeeting taas
05:33:20 <openstack> Meeting started Wed Jun  1 05:33:19 2016 UTC and is due to finish in 60 minutes.  The chair is yamamoto. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:33:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:33:23 <openstack> The meeting name has been set to 'taas'
05:33:48 <yamamoto> #topic Agenda
05:33:57 <yamamoto> #link https://wiki.openstack.org/wiki/Meetings/taas
05:34:17 <yamamoto> #topic Provide Asynchronous API
05:34:31 <yamamoto> kaz: yours?
05:34:33 <kaz> I am adding a status field in API.
05:34:43 <vnyyad> kaz
05:34:58 <vnyyad> Kaz: that will be good
05:35:00 <yamamoto> kaz: great
05:35:03 <kaz> I will submit a patch set in a few days.
05:35:39 <soichi> we'd like to ask your review.
05:35:46 <vnyyad> Kaz: Are enabling a communication path from Agents to Plugin to report status?
05:36:07 <kaz> Not yet.
05:37:05 <vnyyad> Kaz: Ok, I am also going to create a launch pad bug to remove Tap flow objects when the VM is deleted... cleanup
05:37:34 <vnyyad> so for that may be it will be good to have a RPC from agents to plugin... what do you guys things
05:37:36 <vnyyad> think
05:38:31 <vnyyad> Kaz: so is there a plan to have the RPC from agent to Plugin in the future?
05:38:32 <soichi> +1
05:38:59 <soichi> vnyyad: yes, i think so.
05:39:21 <soichi> in the first step, "success" is set as default value
05:39:50 <vnyyad> ok
05:40:35 <yamamoto> vnyyad: do you mean to remove tap-flow on port removal?
05:40:46 <vnyyad> yamamoto: yes
05:41:07 <vnyyad> and also tap-service removal when the tap-service port goes missing
05:41:40 <yamamoto> vnyyad: "tap-service port goes missing"?
05:42:07 <yamamoto> removal of the destination port?
05:42:14 <vnyyad> yes
05:43:14 <yamamoto> vnyyad: all of them are server-side events, right?  i'm not sure how rpc is related to that.
05:44:34 <vnyyad> Yamamoto: i was more thinking of checking in the port on the compute node to see if they are still there and if they go missing then to inform the plugin to delete tap-flows related to that port
05:45:56 <vnyyad> but if we  could monitor the events on the plugin directly... that is listen to the events related to  port deletion then we can do away with the rpc
05:46:30 <yamamoto> vnyyad: it sounds rather confusing than useful to me.   i guess marking objects error/offline/etc makes more sense than deleting them.
05:47:14 <vnyyad> yamamoto: why so?
05:48:23 <soichi> if we remove a tap-service when the tap-service port goes missing, i wonder tap-flows associated with the tap-service need to be removed too.
05:48:40 <vnyyad> soichi: yes it will be a cascade delete
05:48:57 <soichi> okay
05:50:50 <vnyyad> Yamamoto: the idea is to have unnecessary flows from the switches when the ports associated with tap-flow or tap-service go missing
05:52:02 <yamamoto> vnyyad: well, cleanup flows in switches is fine.  removing rest-api level objects sounds unusual.
05:53:22 <vnyyad> Yamaamoto: ok... i get it... i suppose then we can mark it as inactive or some other error in the status
05:53:41 <vnyyad> and latter the admin and check on them and delete them
05:55:46 <vnyyad> about the method to do it... any inputs?
05:56:16 <vnyyad> should we do the detection of port being deleted from the agent or in the plugin
05:58:01 <yamamoto> vnyyad: i'm not sure if unbound ports should be considered as error at all.  eg. vm for the port might have not been launched yet.
05:58:45 <vnyyad> yamomoto: yes that consideration will be made
05:59:27 <vnyyad> unbound port should/will not be deleted
06:00:24 <yamamoto> after all, if an admin is interested in the condition, he can check the status of port.  i'm not sure if reflecting the status to taas objects is so useful.
06:01:33 <soichi> i'm not sure, but
06:01:51 <soichi> if a port is removed implicitly when a VM is deleted explicitly, i think tap-service and tap-flow (rest-api level object) can be removed implicitly with the port.
06:02:02 <vnyyad> yamamoto: i guess its still good to report the status...
06:02:55 <vnyyad> soichi: yes... the proposal is for cases related to the scenario you mentioned
06:03:28 <yamamoto> well, we are talking about agent-level port-unbound event, rather than rest-api level port removal, right?
06:05:02 <vnyyad> yamamoto: agent-level port-unbound event for sure
06:05:33 <vnyyad> but should we not delete the flow if it is a case of rest-api level port removal
06:05:34 <vnyyad> ?
06:06:44 <yamamoto> rest-api level taas objects removal on rest-api level port removal sounds ok to me
06:08:49 <vnyyad> but as soichi said implicit port removal when VM is deleted also should be a case for removing the flows related to taas
06:09:47 <yamamoto> vnyyad: yes, but it doen't need to be tied to agent-level events.
06:10:48 <vnyyad> yamamoto: are you refering to not having the need to do port deletion detection on the agen?
06:11:29 <vnyyad> the idea is the clean up the flows when a port is explicitly or implicitly deleted
06:14:22 <yamamoto> vnyyad: well, we probably need to handle the agent level events for switch flow cleanup.  but no need to remove taas objects for the events.
06:15:36 <vnyyad> yamamoto: sure, we need not delete the taas objects but clean up the flows associated.... but i also think we should change the status on the taas objects
06:16:15 <vnyyad> kaz: will you have the status for both the tap-service  as well as for tap-flow?
06:16:29 <kaz> yes
06:16:37 <vnyyad> kaz: great
06:17:06 <soichi> so, my understand is:
06:17:14 <soichi> 1) tap-service and tap-flow object will be removed in case of port deletion
06:17:31 <soichi> 2) tap-service and tap-flow object should be remained in case of agent-level port-unbound event and an appropriate staus should be set
06:18:40 <vnyyad> soichi: +1, this is better, as in explicit case the is no need to keep taas objects
06:19:47 <yamamoto> FYI, lbaas has two kinds of status; operating_status and provisioning_status.
06:20:31 <soichi> thank you for your information
06:20:38 <yamamoto> one for PENDING_CREATE etc and the other for ONLINE/DEGRADED etc.
06:20:41 <vnyyad> yamamoto: interesting will have a look
06:21:36 <yamamoto> i thought our "status" thing was about PENDING_CREATE etc but what vnyyad is thinking sounds like the other one.
06:22:38 <vnyyad> yamamoto: yes ONLINE/DEGRADED is kind of stuff i am looking at to update
06:23:03 <vnyyad> but cannot the two status be represented by the same field
06:23:43 <yamamoto> vnyyad: maybe.  we need to define the set of possible statuses anyway.
06:23:58 <soichi> yamamoto: +1
06:24:08 <vnyyad> +1
06:24:15 <kaz> +1
06:24:34 <vnyyad> a state machine of sort need to be defined for the status field
06:25:17 <yamamoto> vnyyad: +1
06:25:24 <soichi> agree
06:25:39 <vnyyad> i will submit it by next meeting then so that it can be reviewed
06:25:50 <yamamoto> vnyyad: thank you
06:25:58 <vnyyad> and we can have it in the agenda next time
06:26:36 <soichi> sounds great
06:27:06 <kaz> vnyyad: +1
06:28:02 <yamamoto> #topic Open Discussion
06:28:07 <yamamoto> 2 mins left
06:28:28 <yamamoto> vnyyad: any progress on LP permission update?
06:29:11 <vnyyad> yamamoto: no
06:29:51 <yamamoto> vnyyad: any obstacles?
06:30:20 <vnyyad> not rerally i havent worked on it yet ... so i guess i am the obstacle
06:30:34 <yamamoto> heh
06:31:06 <yamamoto> no time left.  thank you for attending!
06:31:13 <yamamoto> #endmeeting