00:58:54 <zhiyuan> #startmeeting tricircle 00:58:55 <openstack> Meeting started Wed Mar 21 00:58:54 2018 UTC and is due to finish in 60 minutes. The chair is zhiyuan. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:58:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:58:59 <openstack> The meeting name has been set to 'tricircle' 00:59:42 <zhiyuan> let's go through our features 00:59:55 <song> good 01:00:39 <zhiyuan> first, mutable configuration 01:00:58 <song> i have pull a pr for this. 01:02:20 <zhiyuan> yes, I see the patch. the launcher is updated, do we need to also update our configuration definition? 01:03:44 <song> you mean our old configuration definition can not meet the new launcher? 01:04:54 <zhiyuan> I guess we need to define some configuration options as "mutable"? 01:06:19 <song> oh, i follow the nova path to do it. i will see how to do it later. 01:06:43 <song> s /path/patch 01:07:32 <zhiyuan> fine, I think at first we can make log level mutable 01:08:02 <song> and the debug level mutable? 01:08:34 <song> oh that is the same sorry. 01:08:50 <zhiyuan> yeah, log level as debug :) 01:09:10 <song> agree with it. 01:10:16 <zhiyuan> next, new l3 networking model 01:11:14 <zhiyuan> I see the updated spec, can we associate segment with AZ? so we know the segment belongs to which region 01:13:47 <Yipei> i think so, since segments can be associated with aggregate 01:16:55 <zhiyuan> cool, so the information is enough 01:17:17 <zhiyuan> does routed network support updating segment after it's attached to a router? 01:19:20 <Yipei> not tested, i can try it offline. but i think it is supposed to support that 01:23:55 <zhiyuan> ok, I suggest you can discuss the whole process briefly in the spec. like when the local external network is created, it's created synchronously or asynchronously? 01:24:25 <zhiyuan> and whether to support segment update at the first step 01:25:22 <Yipei> ok, got it 01:26:44 <zhiyuan> next, security group deletion 01:27:12 <zhiyuan> I see the smoke test fails with a new error 01:27:41 <xuzhuang> have tested in single node with two pods, tested successfully 01:27:46 <song> I have review the code last day.zhuang zhuang can have a try. 01:28:37 <zhiyuan> 'unicode' object has no attribute 'keys', the error message 01:29:14 <xuzhuang> to song, i have checked but the code is lately 01:31:38 <xuzhuang> s/lately/latest 01:33:44 <zhiyuan> the code that raises exception is: 01:33:55 <zhiyuan> "/opt/stack/new/neutron/neutron/pecan_wsgi/hooks/policy_enforcement.py", line 226, in _exclude_attributes_by_policy 01:34:02 <zhiyuan> for attr_name in data.keys(): 01:34:23 <zhiyuan> data is supposed to be a dict, but it's a string actually 01:34:39 <song> to xuzhuang not the same for check_resource_not_in_deleting 01:34:55 <zhiyuan> need to check why data is not a dict 01:39:17 <zhiyuan> oh, yes, check_resource_not_in_deleting is a bit different 01:40:09 <song> so may merge the new code and rerun. have a look. 01:40:22 <xuzhuang> difference in check_resource_not_in_deleting is for re-delete, joehuang commented network deleting for supporting re-delete 01:42:29 <song> but our spec is not so. 01:43:40 <song> our spec for this come from local return 404 and from user return in deleting. 01:45:20 <xuzhuang> i think the difference in check_not_deleting doesn't cause smoke test fail 01:47:11 <zhiyuan> the implementation in the patch will raise exception to local neutron when network is in deletion, this may affect local neutron 01:49:01 <xuzhuang> oh, should return ResourceNotFound? 01:49:07 <zhiyuan> that's right 01:49:29 <song> and if do not use my new code will affect the logic for network resource delete.see the get_network function in center_plugin.py. 01:50:41 <xuzhuang> oh, i got it, thank you zhiyuan song 01:50:46 <zhiyuan> actually, at the end of delete-network, the deleting-resource record is removed, so we can re-delete 01:51:01 <song> you are welcome! 01:51:27 <zhiyuan> but we need to ensure deleting-resource record is always removed 01:52:01 <zhiyuan> or provide a tool to manually remove the record 01:52:39 <song> just clear the database table for the deleting record? 01:53:01 <zhiyuan> currently, if exception happens during delete network, the record won't be removed since the remove is at the end of "delete network" 01:53:16 <song> yes,that is true. 01:54:49 <zhiyuan> use a try-catch to catch all exception so we can remove the record any time 01:55:03 <song> in the finally? 01:55:56 <zhiyuan> yes, and the try-catch block should include all the "may-raise-exception" code 01:56:44 <xuzhuang> if we remove the record, local neutron may use it continuly 01:57:27 <zhiyuan> remove at the end of deletion 01:58:13 <zhiyuan> and so will be after the process of local neutron 01:59:01 <zhiyuan> we only use deleting-resource to lock the in-delete resource during deletion 01:59:58 <song> that is all right. 02:00:50 <zhiyuan> oh, time's up. xuzhuang, please try updating the function to the latest version 02:01:04 <xuzhuang> oh, hi jiawei the path https://review.openstack.org/#/c/455056/ haven't updated since jun 2017, 02:01:07 <xuzhuang> ok ok 02:01:20 <zhiyuan> and for the metering patch, maybe you can talk about it in our offline group 02:01:32 <xuzhuang> ok 02:01:58 <song> and out team zxh have pull a path for slove the port delete. would you help to review it!thank you ! 02:02:24 <zhiyuan> let's discuss this offline :) 02:02:33 <song> good 02:02:44 <zhiyuan> thanks for attending, bye~ 02:02:50 <song> bye 02:02:53 <zhujintao1> bye 02:02:54 <xuzhuang> bye 02:02:56 <Yipei> bye 02:03:00 <zhiyuan> #endmeeting