14:00:07 #startmeeting neutron_drivers 14:00:08 Meeting started Fri Jun 1 14:00:07 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:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:11 The meeting name has been set to 'neutron_drivers' 14:00:16 hi 14:00:23 Hi there! 14:00:27 hi 14:00:38 welcome manjeet 14:00:47 thanks mlavalle 14:03:05 haleyb: you around? 14:03:18 yes, here 14:03:30 all right, we have quorum then 14:04:05 #topic RFEs 14:04:21 First RFE for today is https://bugs.launchpad.net/neutron/+bug/1460177 14:04:22 Launchpad bug 1460177 in neutron "[RFE] Support metadata service with IPv6-only tenant network" [Wishlist,Triaged] 14:04:41 This is an old RFE, that was accepted a few years ago 14:05:05 This week I was contacted by folks in China, asking for this again 14:05:28 i remember that one 14:06:02 Apparently agencies of the Chinese government soon will start asking for "full IPv6" support. Hence this request 14:06:21 haleyb: I bet you do ;-) 14:06:31 sorry my vpn kicked me out of network 14:07:16 how much of ipv6 support we have now ? 14:07:48 manjeets_: no support for metadata over ipv6 14:08:06 There was a spec half baked: https://review.openstack.org/#/c/315604/ 14:09:23 manjeets_: this has implications beyond Neutron. It has to do with end point addresses across OpenStack services, etc. This is one of the bits pertaining to Neutron 14:10:24 thanks mlavalle haleyb! i'll read the spec to understand neutron bits looks short one 14:12:41 has anything changed in AWS or cloud-init in these few years? 14:12:51 mlavalle: i guess i'm not against the spec, but having been part of the IETF, know it would be best to possibly request an address be registered 14:13:05 i see no ipv6-only support in AWS 14:13:23 yeah, I checked AWS and they don't seem to have changed that 14:13:49 so the concern about modifying AWS-owned API is still valid? 14:14:40 well, I don't know that we concluded we were changing the API 14:15:12 just the target address of the requests 14:15:17 yeah 14:16:56 we could just start using it and send AWS an email, kind-of like StarlingX :-/ 14:17:12 LOL, yeah, let's do that 14:17:21 lol 14:18:05 the address is definitely a part of api. and i suspect we need to change more than that. eg. local-ipv4 14:18:44 config drive is not an option for them? 14:19:43 why not expand the API, making sure we are backwards compatible? 14:19:50 yamamoto: i know we've mentioned it on the ML. So is there an equivalent local-ipv6 in the api? 14:20:45 haleyb: you mean AWS's api definition? 14:21:11 right, it has to be able to return the local ipv6 address i would guess 14:21:34 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html 14:22:09 there seems to be some ipv6 stuff 14:23:42 like network/interfaces/macs/mac/ipv6s 14:23:58 "he IPv6 addresses associated with the interface. Returned only for instances launched into a VPC." seems different from local-ipv4 value 14:26:44 I searched through this doument and didn't find a reference to IPv6 for the metadata service itself 14:27:11 There are references to IPv6 addresses used by the instance 14:28:07 mlavalle: right, i didn't either. i just don't know enough about metadata to know how local-ipv4 is used, or what the instance gets out of it for ipv6 14:29:31 someone more versed in cloud-init or nova would know? i mean, if we can proxy the requests but the instance doesn't get the ipv6 info it needs, we wasted time 14:30:47 haleyb: " to know how local-ipv4 is used". what do you mean by this? 14:31:38 mlavalle: so when an instance uses metadata today, when it reads local-ipv4 what is it used for? 14:32:12 ok 14:32:17 Thanks 14:32:42 i don't know enough about metadata to answer that 14:32:47 i'm not sure what's the requirements of "folks in China". if they just want to be ipv4-free, they can just stop using metadata api. there are alternatives like config drive. 14:35:06 that's an alternative certainly. I will add some comments to the RFE and see if we get more feedback 14:36:23 Let's move on to the next one 14:36:30 https://bugs.launchpad.net/neutron/+bug/1744223 14:36:32 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:37:17 We discussed this one in our last meeting 14:38:07 We agreed that we wanted to make sure the proposed change was only to be able to update external_v6_ip 14:38:28 No response from submitter 14:39:11 So I'm going to leave a note asking if there is still interest in pursuing this 14:39:35 any additional comments? 14:39:53 nothing from me 14:41:46 ok, done 14:42:14 We don't have any more triaged bugs to discuss today 14:42:47 I just want to draw your attention to the following one: https://bugs.launchpad.net/neutron/+bug/1764738 14:42:48 Launchpad bug 1764738 in neutron "routed provider networks limit to one host" [Wishlist,New] 14:43:03 I will be asking some questions today on it 14:43:28 haleyb: you might recognize the submitter from the bug we were talking about yesterday 14:44:37 oh yes 14:45:40 If you can spend some time helping to triage this one, it would be very helpful 14:46:16 #topic Open Agenda 14:46:28 Any other topics we should discuss today? 14:47:11 i have no topic 14:47:28 nada aqui :) 14:47:30 * manjeets_ returns None 14:47:37 LOL 14:47:49 nice Spanish haleyb 14:47:55 nice Python manjeets_ 14:48:06 Thanks for attending 14:48:10 Have a nice weekend 14:48:14 #endmeeting