01:02:02 <zhiyuan> #startmeeting tricircle 01:02:03 <openstack> Meeting started Wed Dec 27 01:02:02 2017 UTC and is due to finish in 60 minutes. The chair is zhiyuan. Information about MeetBot at http://wiki.debian.org/MeetBot. 01:02:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 01:02:06 <openstack> The meeting name has been set to 'tricircle' 01:02:57 <song> hi 01:03:42 <zhiyuan> have just reviewed the spec for reliable resource deletion. though the description needs refined, the overall solution is fine 01:04:02 <song> thanks to zhiyuan 01:04:33 <RongHUI> hello 01:04:56 <song> have just reviewed the spec for reliable resource deletion. though the description needs refined, the overall solution is fine 01:05:11 <song> just now zhiyuan has said. 01:06:58 <zhiyuan> i also see the implementation, but the smoke test fails 01:07:13 <song> yes, I will see it today. 01:07:30 <song> I only test the py27 in my self machine. 01:07:43 <Yipei> please recheck, the patch for callback is merged 01:08:32 <song> good 01:08:35 <Yipei> sorry, still not merged yet, but soon 01:10:46 <zhiyuan> ok, i have just +1 to workflow 01:12:05 <zhiyuan> can check after the patch is merged 01:13:34 <song> to me? that is ok. 01:14:44 <zhiyuan> i see the patch for sfc update is updated, thanks for continuing the work. 01:15:22 <zhiyuan> i think the smoke test also needs to be updated to test the sfc updating case 01:17:07 <xuzhuang> i have a question if in the process of deleting network in several network a local neutron throw exception, how can we complete the deleting continue 01:17:59 <zhiyuan> the exception will be reported to user, and we allow user to retry the deletion 01:18:14 <song> yes 01:18:36 <song> we have a small meeting need to leave sorry for it. 01:18:57 <cyg> to zhiyuan, you're welcome 01:19:07 <zhiyuan> that's fine, song, bye 01:19:26 <xuzhuang> but in the spec i haven't seen this point 01:19:59 <zhiyuan> the part discussing delete-request from user 01:20:42 <RongHUI> sorry, did not add "allow user to retry the deletion" 01:20:55 <RongHUI> will fix in next version 01:22:39 <zhiyuan> but here comes a weird situation. we allow user to re-delete the network if something wrong happens, but if user queries the network, 404 will be returned 01:23:20 <RongHUI> yes' 01:23:37 <zhiyuan> if user forgets the network id, he/she has no way to query the network id ... 01:25:47 <xuzhuang> using resource_id and redo the deletion is not solved this problem? 01:26:55 <zhiyuan> the problem is that, we need users to send the deletion request, but if they forget the network id, they have no way to query it 01:27:08 <zhiyuan> so they cannot send the deletion request again 01:27:51 <RongHUI> if that can we delete the network use network name? 01:28:19 <song> I come back. we also add a api for get the resource_id? 01:28:36 <song> for which in the resource deleting table. 01:28:39 <zhiyuan> API from tricircle? 01:29:00 <song> yes 01:29:07 <zhiyuan> RongHUI, using network name has the same problem 01:30:25 <RongHUI> yes , return 404 to user , if user want to re-delete the network, they can not query for any information about this resource 01:32:34 <xuzhuang> resouceid is same to top id, using resource top id is not enough? 01:32:57 <zhiyuan> i mean, user forgets the top id 01:33:13 <xuzhuang> if it can work, we just need query resourceid 01:33:16 <xuzhuang> to user 01:33:46 <zhiyuan> so song suggests to provide an API for user 01:34:10 <xuzhuang> yeah 01:34:13 <zhiyuan> neutron itself doesn't have such API 01:34:36 <song> yes, or we have error in log, that user know the network_id? 01:35:52 <zhiyuan> the error will be saved in the log of central neutron, but checking the log for the id is not convenient 01:36:22 <song> yes 01:38:25 <zhiyuan> another choice is we just return the resource being deleted 01:38:34 <zhiyuan> not 404 01:38:50 <song> that is good. 01:39:33 <xuzhuang> yeah 01:39:45 <xuzhuang> return 200 01:41:15 <zhiyuan> but we need to tell users that do not use the resource being deleted anymore, only retry deletion is allowed 01:41:40 <RongHUI> can we return both 404 and the resource id to user? 01:42:18 <zhiyuan> that's not a normal http response 01:42:54 <RongHUI> yes 01:43:22 <RongHUI> return two response 01:43:51 <zhiyuan> actually, deletion fails means that the resource exists in database, so it's hard for us prevent the record being used by other API 01:44:00 <zhiyuan> by the API of other resources 01:45:46 <RongHUI> another choice is we just return the resource being deleted +1 01:46:14 <song> another choice is we just return the resource being deleted +1 too 01:46:26 <zhiyuan> RongHUI, so please discuss this situation in the spec, and let's see Joe's comment 01:46:41 <RongHUI> ok 01:47:26 <zhiyuan> so far for this, any other topics? 01:47:33 <song> no for me 01:47:46 <xuzhuang> no from me 01:48:06 <RongHUI> sorry a little question, when the queen publish? 01:48:09 <Yipei> no from me, the spec for l3 networking is almost done, will submit this week 01:48:40 <zhiyuan> Yipei, great! 01:48:54 <zhiyuan> so let's end our meeting, thanks for attending 01:49:02 <song> look like 2018 2 28 01:49:02 <zhiyuan> #endmeeting