14:00:50 #startmeeting neutron_ipv6 14:00:50 Meeting started Tue Jun 3 14:00:50 2014 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:51 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:53 The meeting name has been set to 'neutron_ipv6' 14:01:01 Hello everyone 14:01:12 hello 14:01:14 o/ 14:01:15 Hi 14:01:17 Hi 14:01:29 #link https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_June_3rd Agenda 14:01:36 hi 14:01:54 hi 14:02:23 #topic blueprints 14:02:45 We currently have at least one blueprint that is set for J-1 14:03:28 The blueprint for upstream slaac support was merged last week 14:04:18 I believe we need blueprints created in neutron-specs for the blueprints that cover code changes to dnsmasq 14:04:42 such as https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac 14:05:02 +1 14:05:36 Are there any new BPs to discuss? 14:05:44 sc68cal: I've updated the RA BP neutron spec https://review.openstack.org/#/c/92164/9 14:06:38 sc68cal: I'm working on design spec for multi-IPv6-prefix blueprint, should be out shortly. 14:07:05 dane_leblanc: very cool 14:07:32 I'm working out some kinks on the ipv6 floating IP BP as well 14:07:38 should also be up this week 14:07:43 baoli: I still have some concerns about your proposal to replace the two attribute with a new single attribute 14:07:59 sc68cal, I think someone mentioned IPv6 metadata in email discussion. I am very interested and want to investigate more. 14:08:15 Firstly, we started from a single attribute back during the Havana timeframe 14:08:31 then through this subteam determined that two attributes was more suitable 14:08:58 sc68cal: I understand your concerns 14:09:33 This is only my opinion, but we'd pretty much have to stop all the work we're doing and go back to square one. That means no real IPv6 support untill probably K timeframe 14:09:58 baoli: I'm curious. You mention in the spec that the two attrib approach uses two copies of dnsmasq and list that as a drawback. How do you intend to have a dhcpv6 network and route packets without something else to issue RAs? 14:10:37 xuhanp: cool - yeah metadata is tricky since AWS has no ipv6. 14:10:48 aveiga, the spec talks about RAs, right? 14:10:54 yup 14:11:30 sc68cal, can we discuss the comments in the dnsmasq patch? 14:12:11 baoli: if there are no further blueprints, yeah I can advance the topic to code review 14:12:17 sc68cal, one of the reasons for me to propose the one attribute (I understand it's kind of late in the sicussion) is after reviewing the changes in very detail 14:12:43 sc68cal, sure 14:13:07 #topic code review 14:13:20 do you have a link, there's a couple patches re dnsmasq 14:13:40 https://review.openstack.org/#/c/70649/15/neutron/agent/linux/dhcp.py 14:14:36 so the values of the two attributes are used to determine the command line for dnsmasq, and there are some concerns on how that's done in the patch. 14:16:27 baoli: ok 14:16:37 I also want to add that the current dhsmasq impelentation as it is works for ipv6 14:17:04 what is missing is the RA + SLAAC. 14:17:42 We've encountered a number of bugs with the current code as it stands - I'm not sure what you mean by the current impl as it is works for ipv6 14:18:12 sc68cal, the latest code from upstream. 14:18:44 ok - can you please start a thread on the ML with more details 14:18:57 sc68cal, I apologize for reintroducing the one attribute at this point of the game. But I'm hoping it's for good reasons. 14:19:34 sc68cal, you mean starting a thread on the one attribute versus two attributs? 14:20:08 I was thinking details for what you mean by the current dnsmasq implementation as it is works for ipv6 14:20:35 if you want to start a thread on 1 attribute vs 2 - feel free to as well 14:20:51 but we're basically 1 week away from J-1 14:20:56 sc68cal, do you want the thread to cover how it works now? 14:21:19 We can continue to debate changing API attributes or we can start working on getting dnsmasq working properly 14:22:13 sc68cal, by making it work properly, you mean the DHCP part or the RA part? 14:22:28 Most likely both 14:22:51 and fixing an existing issue where a bad host file with v6 addresses causes dnsmasq to crash, and stop issuing ipv4 leases 14:23:26 what is the bug number for that? 14:25:07 #1257446 14:25:16 https://bugs.launchpad.net/neutron/+bug/1257446 14:25:20 Launchpad bug 1257446 in neutron "Creating a dual-stacked network causes dhcp for both stacks to fail" [Medium,Triaged] 14:26:51 are there any other code reviews anyone would like to discuss? 14:27:21 I'm now running a dual stack testbed, and it seems to be working fine now 14:29:12 baoli: then can you share the details of your configuration 14:29:21 how you created the network and subnet in the api 14:29:23 etc.. 14:29:27 on the mailing list 14:29:36 sc68cal, sure 14:30:11 Any other code reviews, or shall we continue on to bugs 14:30:43 the devstack change 14:31:18 link? 14:31:19 I am going to follow sean dague's recommendation to submit patch for the mgmt net. 14:31:45 https://review.openstack.org/#/c/87987/ 14:32:13 perfect 14:34:44 #topic bugs 14:35:02 baoli: have you written up a bug report for the floating ip issue we discussed last week 14:35:10 yes, I did 14:35:16 let me find the link 14:36:20 https://bugs.launchpad.net/neutron/+bug/1323766 14:36:21 Launchpad bug 1323766 in neutron "Incorrect Floating IP behavior in dual stack or ipv6 only network" [Undecided,New] 14:38:13 perfect, I have added that to the main meeting agenda to discuss next monday 14:38:29 sc68cal, thanks 14:38:38 markmcclain said that it might be just that the order is determined by the ordering in the database layer 14:38:54 for whatever the query they build 14:39:40 any other bugs to discuss? 14:40:28 [redacted spam] 14:40:36 [redacted spam] 14:40:43 [redacted spam] 14:40:46 [redacted spam] 14:40:52 [redacted spam] 14:40:56 [redacted spam] 14:41:02 [redacted spam] 14:41:09 [redacted spam] 14:41:12 [redacted spam] 14:41:19 [redacted spam] 14:41:27 [redacted spam] 14:41:29 [redacted spam] 14:41:34 anyone an op here to kick ^^ 14:41:36 [redacted spam] 14:41:39 [redacted spam] 14:41:45 [redacted spam] 14:41:51 [redacted spam] 14:41:57 [redacted spam] 14:42:04 [redacted spam] 14:42:07 haleyb: +1 14:42:10 [redacted spam] 14:42:16 [redacted spam] 14:42:22 [redacted spam] 14:42:25 [redacted spam] 14:42:32 [redacted spam] 14:42:55 thanks jeblair 14:43:31 Well.... 14:44:45 So uh, any more bugs to discuss? 14:45:47 #topic open discussion 14:47:44 sc68cal, were you able to talk to Shi Xiong to start to get those review comments addressed? 14:48:13 xuhanp: I sent an e-mail to him yesterday to see if he had time to talk 14:48:25 I have not heard a response back 14:48:26 good to hear that. Thanks 14:48:53 if you have a chunk of that patch that you want to take and work on, please do 14:49:02 worst case you can give him attribution in the commit message 14:50:41 sc68cal, just want to make sure we split that smartly so it can be reviewed well. 14:50:55 may need some overall plan to do that. 14:51:14 xuhanp: agree. I just realized that the patch is abandoned 14:51:35 sc68cal, yeah. it gets -1 for a while. 14:51:46 so I don't think we have much we can do to that specific review until we get a hold of Shixiong and have him restore it 14:52:15 ok 14:52:16 at this point I think we just need to tear the band-aid off and take parts of that commit and rework and submit new reviews 14:52:43 xuhanp: so if you have a piece you want to work on, go ahead. Just make sure to also submit a BP to neutron-specs 14:52:59 sc68cal, OK. will do. 14:57:48 OK - if there is nothing else I think we'll bring this meeting to a close 14:58:25 I'm in the -neutron IRC channel as usual 14:58:32 take care everyone! 14:58:40 #endmeeting