14:00:51 <mlavalle> #startmeeting neutron_drivers 14:00:52 <openstack> Meeting started Fri Oct 26 14:00:51 2018 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:55 <openstack> The meeting name has been set to 'neutron_drivers' 14:01:41 <yamamoto> hi 14:01:49 <mlavalle> hi 14:02:07 <amotoki> hi 14:02:10 <hle2> hi 14:02:14 <kailun> hi 14:02:32 <bcafarel> sorry I kept a few drivers busy, they should get in soon 14:02:51 <mlavalle> bcafarel: LOL 14:02:58 <slaweq> hi 14:03:02 <haleyb> hi 14:03:12 <mlavalle> ok, we have quorum now 14:04:22 <mlavalle> hle2, kailun: are you here to discuss something with the team? 14:05:12 <njohnston> o/ 14:05:13 <kailun> mlavalle: yes, I have one RFE to discuss 14:05:26 <mlavalle> kailun: do you have the pointer? 14:05:40 <kailun> https://bugs.launchpad.net/neutron/+bug/1795212 14:05:40 <openstack> Launchpad bug 1795212 in neutron "[RFE] Prevent DHCP agent from processing stale RPC messages when restarting up" [Wishlist,In progress] - Assigned to Kailun Qin (kailun.qin) 14:06:15 <kailun> And the patch is available @ https://review.openstack.org/#/c/609463/ 14:06:59 <kailun> I'd like to have the idea triaged and move forward :) 14:10:17 <Chenjie> Hello everyone, I have an RFE that I want to discuss. 14:10:20 <slaweq> kailun: I think I don't understand bug You described there 14:10:33 <Chenjie> https://bugs.launchpad.net/neutron/+bug/1793653 14:10:33 <openstack> Launchpad bug 1793653 in neutron "[RFE] Enable other subprojects to extend l2pop fdb information" [Wishlist,In progress] - Assigned to ChenjieXu (midone) 14:11:07 <Chenjie> The patch is available https://review.openstack.org/#/c/599319/ 14:11:20 <slaweq> host with agent goes down and is rebooted, neutron-server rechedule networks from this dhcp agent to another ones, then host is booted again - what rpc messages it will have then? 14:14:20 <mlavalle> I see haleyb is co-author of the patch 14:15:01 <kailun> slaweq: the rpc sent to the agent before the agent is down 14:15:06 <haleyb> well, i helped update it but it wasn't my original idea 14:15:32 <slaweq> and how that short (I guess) delay can help to solve this problem? 14:15:38 <kailun> slawek: a schedule rpc for instance 14:16:05 <slaweq> shouldn't it be solved e.g. by smaller ttl time for messages in rabbitmq? 14:18:07 <kailun> slaweq: the agent will block the rpc messages during the init delay and have an active sync state to get the up-to-date info from the sever after that delay 14:18:20 <haleyb> i was also wondering about doing it without a config option somehow, since if it's a bug the default should be to enable the 'wait' 14:18:25 <amotoki> IIRC, when dhcp-agent is restarted, full sync will be done, right? 14:18:36 <amotoki> If so, when RPC msgs older than full sync arrives, we can drop them. perhaps this is what the timestamp based solution tries to do. 14:18:37 <kailun> slaweq: ttl is another way IMO 14:18:38 <mlavalle> amotoki: yes 14:19:41 <amotoki> I think the complicated case is where delayed msgs arrive after full sync, but I am not sure this happens. 14:20:17 <slaweq> amotoki: ok, I understand now "timestamp" solution 14:20:24 <amotoki> kailun: is my understanding correct? 14:20:40 <slaweq> but proposed patch was doing this second approach (delay): https://review.openstack.org/#/c/609463/ 14:21:11 <slaweq> and in fact how You want to be sure then that agent waited enough time and will not consume some stale message anyway? 14:22:44 <haleyb> would the other alternative be to use the Resource queue like the l3-agent? 14:22:49 <amotoki> yeah, I see it too. 14:23:19 <kailun> amotoki: yes 14:23:20 <amotoki> what I am not sure so far is what kind of corner cases and negative behaviors could happen (even with full sync) 14:23:34 <kailun> sorry guys my connection is unstable :) 14:24:51 <amotoki> kailun: you can follow up the discussion at http://eavesdrop.openstack.org/meetings/neutron_drivers/2018/neutron_drivers.2018-10-26-14.00.log.txt (with little delay) 14:26:08 <slaweq> haleyb: yes, Resource queue with ExclusiveResourceProcessor should maybe be better idea IMO 14:26:20 <kailun> amotoki: dhcp does not have a timestamp support right now, correct? 14:26:36 <haleyb> slaweq: that was one reason i moved it from under l3 14:26:40 <kailun> amotoki: while l3 agent has one I guess 14:27:37 <amotoki> kailun: i cannot answer it immediately. does anyone know it? 14:27:49 <slaweq> also, one more question 14:28:25 <slaweq> I don't remember exactly but in some (very) old releases rpc queues which agent's registered had some random id 14:28:33 <kailun> slaweq: I also tried to evaluate timestamp and the delay I proposed, I did not see a obvious drawback 14:28:45 <slaweq> so when agent was e.g. restarted it created new queue and would not consume messages from this old one 14:28:50 <slaweq> isn't it like that anymore? 14:29:45 <kailun> slaweq: I don't have an answer to this one, I can double check 14:30:06 <slaweq> kailun: would be good IMO to check that 14:30:39 <amotoki> it seems we need to clarify failure modes in question, i.e., what actually happens before discussing a solution. 14:30:53 <kailun> slaweq: sure I'll do that 14:30:53 <slaweq> amotoki++ 14:32:09 <kailun> amotoki: agree, let me follow up with this one 14:32:28 <mlavalle> kailun: based on this discussion, let's continue the conversation in the RFE 14:32:36 <amotoki> slaweq and I raises several questions. let's follow them up on the bug 14:33:11 <slaweq> amotoki: mlavalle: I agree, let's follow up on RFE 14:33:47 <kailun> mlavalle: slaweq: amotoki: haleyb: let's follow them up on the bug 14:33:59 <mlavalle> kailun: thanks 14:34:06 <amotoki> kailun: thanks for raising this 14:34:33 <mlavalle> kailun: and thanks for your patches. I think we merged one yesterday, didn't we? 14:34:38 <mlavalle> also DHCP 14:35:13 <kailun> yes thank you all for the review and discussion 14:35:25 <mlavalle> I liked the way you used the Event object ;-) 14:36:09 <mlavalle> and the throttling, which was a concern when we approved that RFE 14:37:07 <kailun> :) every concern has a solution 14:38:08 <mlavalle> ok, now let's move on to https://bugs.launchpad.net/neutron/+bug/1793653 14:38:08 <openstack> Launchpad bug 1793653 in neutron "[RFE] Enable other subprojects to extend l2pop fdb information" [Wishlist,In progress] - Assigned to ChenjieXu (midone) 14:38:36 <Chenjie> mlavalle: thanks! 14:39:58 <mlavalle> Chenjie: I saw this one a little more than a week ago and asked in the bug to keep the status as New, so it doesn't slipped thorugh our screen 14:40:17 <mlavalle> but apparently you pushed a patch and the status was changed 14:40:20 <mlavalle> that's ok 14:40:43 <mlavalle> The leasson for us is we need to update that screening criteria 14:40:57 <Chenjie> mlavalle: sorry for that! 14:41:43 <mlavalle> Chenjie: no worries. it's really a lesson for me that I need to improve that screening criteria 14:42:07 <amotoki> regarding the status, we now use tags to track RFE states (rfe, rfe-confirmed, rfe-triaged), so i think LP bug status does not matter us. 14:42:38 <mlavalle> amotoki: yeah, but this one slipped through the cracks somehow 14:42:53 <mlavalle> It didn't show up yesterday when I was preparing for the meeting 14:44:03 <mlavalle> Chenjie: anyways, the upshot is that we may finish reviewing your rfe today and we would continue the discussion in the RFE clarifying 14:45:17 <Chenjie> mlavalle: thank you very much! 14:45:49 <Chenjie> thank you all! 14:46:05 <mlavalle> Chenjie: thanks for your submission, first of all 14:46:32 <mlavalle> Chenjie: question: is this being proposed in the context of bgpvpn-networking? or it is just an example? 14:47:56 <amotoki> we can first discuss the problem statement and what is needed (before going into the detail of the solution) in the RFE. The detail can be discussed in the spec. 14:48:23 <Chenjie> mlavalle: Yes, it is. But this can be used by other subprojects. 14:49:10 <amotoki> Chenjie: are there any usecases in other subprojects in your mind? 14:49:25 <munimeha1> hi 14:49:58 <amotoki> I understand it can potentially be used by other projects of course 14:50:18 <mlavalle> amotoki, haleyb, slaweq, yamamoto: here's the figure mentioned in the rfe: https://launchpadlibrarian.net/389540006/rfe_EXTEND_L2POP_FDB_INFORMATION.PNG 14:50:30 <Chenjie> amotoki: For now another RFE has been drafted to add l2pop support for floating ip resources. This can be used in here. 14:51:49 <Chenjie> amotoki: yes, other projects can use this. 14:52:09 <amotoki> Chenjie: thanks, I see. 14:52:38 <Chenjie> amotoki: the name should be changed to "Enable other projects to extend l2pop fdb information"? 14:53:59 <amotoki> Chenjie: I am not sure now. If another RFE requests more and it affects the design/direction of this RFE, it is better to be considered. 14:54:24 <amotoki> otherwise, the current title sounds good 14:54:42 <mlavalle> yeah, the title looks good to me. don't worry about it 14:54:51 <amotoki> Chenjie: let's understand and discuss the current usecase first. 14:55:03 <Chenjie> thanks! 14:55:17 <liuyulong> slaweq, https://bugs.launchpad.net/neutron/+bug/1796824, I'd like to raise this to the meeting, since the patch is almost done here: https://review.openstack.org/#/c/608909/ 14:55:17 <openstack> Launchpad bug 1796824 in neutron "Port in some type of device_owner should not allow update IP address" [Medium,In progress] - Assigned to LIU Yulong (dragon889) 14:56:21 <liuyulong> And here: https://review.openstack.org/#/c/612969/ 14:56:27 <yamamoto> does bgpvpn assume l2-agent based networks? 14:57:39 <slaweq> liuyulong: lets follows mlavalle's order in the meeting - he is chair here :) 14:59:11 <mlavalle> Chenjie: I went over the your proposal and in principle it makes sense to me. I would like to go over it again 14:59:13 <Chenjie> yamamoto: Do you mean networking-bgpvpn uses l2-agent(ovs and linuxbridge agent)? 14:59:35 <Chenjie> mlavalle: Thank you very much! 14:59:49 <mlavalle> and we can retake it next week 15:00:05 <mlavalle> we ran out of time today 15:00:12 <yamamoto> i meant if it didn't work for other l2 impl like odl 15:00:27 <slaweq> thx, and have a great weekend guys :) 15:00:28 <slaweq> o/ 15:00:37 <yamamoto> i'll ask on rfe 15:01:09 <mlavalle> also if you have time, please look at https://review.openstack.org/#/c/574477 15:01:15 <Chenjie> mlavalle: thank you very much! 15:01:18 <mlavalle> spec is ready for next rund of review 15:01:23 <mlavalle> #endmeeting