14:01:34 #startmeeting neutron_ipv6 14:01:35 Meeting started Tue May 27 14:01:34 2014 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:38 The meeting name has been set to 'neutron_ipv6' 14:01:43 Who's here for IPv6? 14:01:50 hello everyone 14:01:57 Hi 14:01:58 Hello 14:02:28 #link https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_May_27th 14:02:29 Hi 14:03:05 #topic blueprints 14:03:42 #info Make sure you are creating blueprints in the neutron-specs repo and submitting to gerrit 14:04:12 #link https://wiki.openstack.org/wiki/Blueprints#Neutron Blueprint info 14:04:33 Do we have any blueprints to discuss? 14:07:30 OK - if not we will continue on to code reviews 14:08:10 #topic code reviews 14:08:40 sc68cal, I restore my client code change, but seems like Mark still has the -2 on it. 14:08:40 xuhanp: I e-mailed mark mcclain to ask him to clear his -2 for your python-neutronclient change 14:08:54 #link https://review.openstack.org/#/c/75871/6 Python-neutronclient change for ipv6 attributes 14:09:02 :-) we are thinking about the same thing 14:09:04 :) 14:09:23 #info markmcclain needs to clear -2 since we're in Juno release 14:09:52 I hate to put a strong voice in the logs like that, but the -2 was because he didn't want it in the Icehouse release 14:10:19 We may need to really get moving on the implementation patches that orchestrate dnsmasq 14:10:30 +1 14:10:33 to help facilitate the clearing of that -2. 14:11:02 So - looks like Shixiong Shang is not online - I'm going to make an executive decision and start breaking up his patches into smaller chunks 14:11:28 then offering them to people to work on 14:11:48 sc68cal, let me know what I can help. We have env in our lab to test it. 14:12:02 Pefect 14:12:13 #link https://review.openstack.org/#/c/70649/ Dnsmasq IPv6 patch that needs to be broken up 14:12:36 #action sc68cal break that review into pieces so we can have multiple people working on the patch 14:13:13 I didn't see responses to the comments people had posted to the review. 14:14:04 There were ~50 comments on the review, it probably just got too big to really handle 14:14:45 Some fundamental comments need to be addressed, at least 14:15:47 agree - when we break it up we'll need to consult the comments of that review to help guide the work 14:16:43 Before I forget - xuhanp mentioned he has a lab to test the patches - I'm also working with SridharG to add API tests to Tempest, and scenario tests for IPv6 functionality 14:16:55 so we can get things testing at the gate 14:17:34 sc68cal, sure. That should be easy to test since tempest is still all-in-one node, right? 14:18:33 Not 100% sure - there has been a lot of work to start doing multi node- but I don't know the status of that work 14:18:52 #link https://review.openstack.org/#/c/93502/ Tempest IPv6 attribute tests 14:19:27 I think I need to update that review, it is possible that they removed testtools as a dependency for tempest in the last couple days 14:19:47 went from passing (except for icehouse) to failing completely :-\ 14:20:57 hmm no it's still a dependency. Well going to have to figure that one out. testr has the most useful error reporting 14:22:11 do we have any other code reviews to discuss? 14:22:55 sc68cal, I also has a code review to discuss 14:22:56 #link https://review.openstack.org/#/c/76125/ 14:22:58 it has been there for a while, and baoli and I were discussing about this on mail list 14:23:34 I would like to hear team's opinion on this. 14:24:09 http://lists.openstack.org/pipermail/openstack-dev/2014-May/034914.html 14:24:14 here is the email discussion 14:25:15 xuhanp: I agree with your analysis about allowing two LLA's for a subnet 14:25:18 The major concern about attaching subnet with LLA gateway to a router will cause the gateway port has two LLA addresses. 14:25:24 sc68cal, yep 14:25:44 I'm temptest to just say, if you attach a router to a subnet that already has a LLA set - *overwrite it* 14:25:48 *tempted 14:26:03 although on second thought - multiple routers attached to a subnet 14:26:13 for east-west traffic 14:26:51 sc68cal, by "overwrite" you mean use the IP in the subnet instead? 14:27:25 no I was thinking take the LLA of the router when it is attached to the subnet and replace the gateway attr of the subnet (if set) 14:27:56 most of the time people are not going to set the gateway IP of a subnet then attach a router 14:28:15 they'll most likely create a subnet with just the cidr and ip version then attach a router 14:28:19 I see 14:28:47 So perhaps throw an error if the gateway attr is already set when attempting to attach a router? 14:29:02 Until we can think of something to handle multiple routers attached to a subnet 14:29:19 I have to take a look at the extraroute attributes 14:29:24 yep. that makes sense. Let me think about that. 14:30:12 To be honest I don't know how much of a problem this is *right now* since we don't have dnsmasq fixed yet 14:30:24 but it certainly will become a problem once we get that working 14:30:47 sc68cal, agree that the dnsmasq fix has higher priority. 14:31:56 anything else before we turn to bugs? 14:33:17 #topic bugs 14:33:22 #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6 14:33:32 We have some new and interesting bugs :) 14:33:44 #link https://bugs.launchpad.net/neutron/+bug/1322945 14:33:45 Launchpad bug 1322945 in neutron "Attaching a IPv6 private subnet to a L3 Router, breaks it and its IPv4 Floating IPs" [High,New] 14:34:37 sc68cal, when working on the SNAT bug, in the review, we discussed issues associated with ipv4 floating ip. 14:35:11 https://review.openstack.org/#/c/88584/1/neutron/agent/l3_agent.py 14:35:36 The comments talked about some issues 14:35:56 I was wondering if a BP is needed to address them all 14:37:04 My first thought is just to file a bug(s) 14:37:23 it sounds just like misbehavior 14:37:45 The ipv4 floating ip api needs to be looked at in the context of ipv4 and ipv6 together 14:37:55 agree 14:38:33 aveiga is out this week but we're working on a way to do floats in v6, without NAT 14:39:07 but yeah dual stack floating ips - probably nobody has thought of that 14:40:06 baoli: I'll make a note to bring this up at the main meeting - this is a very interesting issue 14:40:23 #action sc68cal bring up baoli's analysis of the floating ip API and dual stacking in the main meeting 14:40:46 baoli: for the time being can you write up a bug so I can link it for them? 14:40:52 sc68cal, that would be great. It should be considered in the case of dual stack and ipv6 only 14:41:05 sc68cal, will do. 14:41:22 #action baoli write up bug report about dual stack and v6 only floating ips 14:42:12 So the other bug I wanted to bring attention to is this one 14:42:16 #link https://bugs.launchpad.net/ironic/+bug/1323152 14:42:18 Launchpad bug 1323152 in ironic "CI failure "unable to enable dhcp for" (dup-of: 1321494)" [Undecided,New] 14:42:19 Launchpad bug 1321494 in ironic "NodeLocked causing random test failures" [High,In progress] 14:42:35 basically dnsmasq barfs on a v6 subnet 14:43:00 I'm sure we've all seen that error in devstack when testing v6 :) 14:43:58 so - I think one of the fixes is bumping the dnsmasq min version 14:44:13 https://bugs.launchpad.net/neutron/+bug/1233339 14:44:15 Launchpad bug 1233339 in neutron "bump dhcp.Dnsmasq.MINIMUM_VERSION" [Medium,Triaged] 14:44:36 the other fix is getting the dnsmasq patches for v6 merged :) 14:45:41 Any other bugs to discuss? 14:45:49 otherwise I'll turn to open discussion 14:46:37 #topic open discussion 14:50:49 If there's nothing else to discuss, I can give everyone back 10 minutes and end the meeting 14:51:13 :-) 14:51:56 Ok everyone, take care, see you all next week! 14:51:59 #endmeeting