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