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