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