14:00:53 #startmeeting neutron_drivers 14:00:53 Meeting started Fri May 18 14:00:53 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:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:56 The meeting name has been set to 'neutron_drivers' 14:01:04 Hi there! 14:02:27 hi 14:03:03 amotoki: when are you flying to Vancouver? 14:03:26 tomorrow evening and I will arrive at Vancouver Saturday 14:03:50 18 hours later from now 14:04:08 right, you gain time crossing the international time line 14:04:30 I will lose one day when returning to Japan :) 14:04:38 it's as though you are flying West, even though you are flying East 14:04:54 :) 14:05:12 let's wait a little for yamamoto and haleyb to join 14:05:26 * haleyb was in the neutron channel 14:05:33 I see haleyb in the neutron channel 14:06:10 I knew you were there. I just tried to be respect your conversation with slaweq 14:06:20 ok, let's begin 14:06:31 #topic Announcements 14:06:46 Just to make sure, we won't have meeting next week, due to the Summit 14:06:59 We will resume on June 1st 14:07:07 any other announcements? 14:07:42 none from me 14:07:45 ok, let's move on 14:07:52 #topic RFEs 14:08:40 First one for today. We are re-visiting https://bugs.launchpad.net/neutron/+bug/1766380 14:08:41 Launchpad bug 1766380 in neutron "[RFE] Create host-routes for routed networks (segments)" [Wishlist,Confirmed] 14:08:55 Submitter provided answer to our question of last week 14:09:59 the submitter assumes it is visible to the API. 14:10:14 that is his intent, yes 14:10:43 I am fine with this. 14:10:51 me too 14:11:05 +1 14:11:10 cool 14:11:19 hang on, let me update the RFE 14:11:45 this will raise another question on relationship between PUT and automatic router from routed network, but I am okay to always populate automatic routes. 14:12:25 if we need more improvement, we can explore more then. as the first step the current proposed solution sounds fine to me. 14:13:23 Next one is https://bugs.launchpad.net/neutron/+bug/1768690 14:13:25 Launchpad bug 1768690 in neutron "[RFE] Regenerate mac address of a port" [Wishlist,New] - Assigned to Harald Jensås (harald-jensas) 14:15:54 it was discussed a bit at the end of the last meeting http://eavesdrop.openstack.org/meetings/neutron_drivers/2018/neutron_drivers.2018-05-11-14.00.log.html#l-88 14:16:15 yeap 14:16:19 we ran out of time 14:16:42 he is esentially proposing a new API extension 14:17:11 haleyb's questions in the bug cleared all points on motivations to me. 14:17:14 where the user (Ironic in his use case) can request a MAC to be re-generated for a port 14:17:29 i think this is a reasonable workaround to this problem. 14:17:35 This is the extension in neutron-lib 14:17:40 https://review.openstack.org/#/c/565931/ 14:18:00 yes, a new API extension makes sense 14:18:36 and this is what it would look like in the DB core plugin: 14:18:40 https://review.openstack.org/#/c/565932/2/neutron/db/db_base_plugin_v2.py 14:19:12 Makes sense to me as well 14:22:24 you ok with it haleyb? 14:22:51 yes 14:23:04 ok, cool, let me approve it. hang on 14:25:54 Next one is https://bugs.launchpad.net/neutron/+bug/1744223 14:25:56 Launchpad bug 1744223 in neutron "[RFE] VPNaaS: handle local side's tunnel IP in ipsec-site-connection operations" [Wishlist,Confirmed] - Assigned to Hunt Xu (huntxu) 14:30:47 it seems #5 describe the actual need. 14:31:05 yeap 14:31:29 after yamamoto's question, I think we got to clarify the use case 14:32:15 the original RFE description mentions more than that, for example updating router gateway IP when VPN connections exist. 14:33:12 I am not sure we can change gateway IP during ipsec site connection.... 14:33:26 so I think we should focus on comment #5 14:33:42 that's a good point 14:36:27 I would like to check how the current vpnaas endpoint group behaves more (while yamamoto might know all) 14:36:50 that would be very helpful 14:37:15 is that something you could do between today and next meeting (June 1st)? 14:37:30 mlavalle: I believe so 14:38:03 ok, I'll leave a note to this effect in the RFE and let him know we will take next step on June 1st 14:38:20 sounds good 14:38:23 the other thing is that yamamoto will be in Vancouver as well 14:38:34 so we can talk about it there 14:39:05 hi. sorry late 14:39:19 hey yamamoto 14:39:29 yamamoto: welcome :) 14:39:44 we were looking at https://bugs.launchpad.net/neutron/+bug/1744223 14:39:45 Launchpad bug 1744223 in neutron "[RFE] VPNaaS: handle local side's tunnel IP in ipsec-site-connection operations" [Wishlist,Confirmed] - Assigned to Hunt Xu (huntxu) 14:40:07 the submitter left a follow up response to your question 14:40:22 what do you think 14:40:31 i haven't read the response yet 14:40:44 take a look, we are patient 14:41:52 * yamamoto reading 14:46:32 i was missing it has ipv6 when i asked the question. his response makes sense to me. 14:46:54 it made sense to me as well 14:47:37 amotoki had some concerns before you showed up regarding the endpoint group 14:47:47 maybe you can help with that? 14:48:11 yamamoto: does it mean a gatewap address is updated to support IPv6 vpn connection later? 14:48:18 iirc external_xxx_ip field is working this way because someone wanted to allow their backend to choose the addresses. 14:48:19 s/gatewap/gateway/ 14:49:55 I am just wondering how external_xx_ip (db caches) and endpoint group updates affect each other. 14:50:23 my understanding is he want to allow updating external_v6_ip when there are only ipv4 site connections. 14:50:41 right, that is what I understood 14:50:55 ah, good point. 14:51:11 I might see too much 14:52:22 when IPv6 is not used in vpn connections it makes sense to update external v6 IP of routers. 14:52:23 so, would we be ok approving this, clarifying that we understand that what he wants to do is updating external_v6_ip? 14:52:47 maybe ask the clarifying question first and upon his response, then approve 14:52:59 i think so 14:53:14 i first thought it was more difficult things like using different addresses for every site connections but what he wanted was something more simple it seems. 14:53:57 ok, I'll leave a clarifying comment, and we go from there 14:54:41 #topic Open Agenda 14:54:53 yamamoto: I have a request for you 14:55:17 I am going to give a Neutron update on Monday in the morning to the community 14:55:38 and I including the stadium projects in that update 14:56:10 in 1 section, I am giving highlights of features delivered in Queens 14:56:24 I took what I found in the relase notes 14:56:41 would you review what I put for midonet and vpnaas? 14:56:48 sure 14:57:23 for vpnaas, the biggest news is neutron-vpnaas is now back to the stadium :) 14:57:25 there is another section with key features planned for Rocky 14:57:58 would you write the highlights of planned features for vpnaas and midonet? 14:58:06 2 or 3 for each 14:58:41 yamamoto: ^^^^ 14:58:44 well, i have no plan :-) 14:58:57 whatever you can update will be appreciated 14:59:14 mlavalle: for vpnaas, I can pick some ongoing efforts from the current review activities 14:59:26 amotoki: that will help 14:59:28 (though I am not sure they can land in Rocky) 14:59:37 that's ok 14:59:48 i will send you a mail on that tomorrow 15:00:07 amotoki: ok, send it miguel@mlavalle.com 15:00:15 sure 15:00:15 yamamoto: ^^^^ 15:00:29 ok guys have a safe trip 15:00:35 see you in Vancouver 15:00:40 #endmeeting