14:00:44 <sc68cal> #startmeeting neutron_ipv6
14:00:45 <openstack> Meeting started Tue Apr  8 14:00:44 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:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:48 <openstack> The meeting name has been set to 'neutron_ipv6'
14:00:51 <sc68cal> #link https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_April_8th Agenda
14:01:11 <sc68cal> #topic blueprints
14:01:18 <xuhanp> hello
14:01:32 <sc68cal> So - real quick on this one, since I don't know if Mark has e-mailed the announcement yet for neutron-specs
14:01:54 <baoli> hi
14:02:05 <dzyu> hello
14:02:20 <sc68cal> so polish up your RST syntax and get ready to submit blueprints through the new workflow once it is announced.
14:03:18 <xuhanp> sc68cal, will the blueprint be reviewed and approved just like code?
14:04:03 <sc68cal> xuhanp: I believe so. That was one of the things mentioned when the Nova team proposed it
14:04:20 <sc68cal> currently it is difficult to review BPs on launchpad
14:04:37 <sc68cal> <sarcasm> There's no -1 button </sarcasm>
14:04:39 <xuhanp> sc68cal, got it. Thanks
14:05:32 <sc68cal> #link https://blueprints.launchpad.net/openstack/?searchtext=ipv6
14:06:38 <sc68cal> ( Sorry for running this meeting tightly, my latent Type A Personality has resurfaced )
14:06:49 <sc68cal> hence the agenda and such :)
14:07:17 <sc68cal> anything else for Bp's - or should we move on to code reviews
14:08:29 <sc68cal> #topic code review
14:08:31 <dzyu> xuhanp: what about our support code about ipv6 mode in CLI?
14:09:09 <xuhanp> dzyu, it has been -2'ed by Mark
14:09:26 <dzyu> it should be one BP
14:09:44 <sc68cal> I can explain that one - there's a patch that they're working to get merged for Icehouse that hides the IPv6 attributes
14:09:50 <sc68cal> #link https://review.openstack.org/#/c/85869/ Hide ipv6 attributes for Icehouse
14:10:04 <sc68cal> So they'll merge it - and when the stable/icehouse branch is cut they'll revert
14:10:38 <dzyu> OK
14:10:46 <xuhanp> sc68cal, that's fine since we only support provider IPv6 after all, right?
14:10:48 <sc68cal> They're saying that it's going to be only a couple hours where that commit will be active
14:10:56 <sc68cal> then they'll revert
14:11:26 <aveiga> so which modes do we officially support at this point with those patches disabled?
14:11:34 <sc68cal> At this point - none
14:11:38 <aveiga> it might be useful to nail them down for official use docs
14:11:39 <aveiga> ok
14:12:09 <sc68cal> I'm working on rebasing the work done by dzyu and xuhanp to allow provider RAs
14:12:50 <sc68cal> but the good news is we got the sec group RA logic merged - big props to Xuhanp
14:13:22 <xuhanp> sc68cal, thanks! I didn't expected that was able to be merged :-)
14:13:33 <sc68cal> :)
14:13:35 <baoli> good job, xuhanp
14:13:42 <shshang> +1
14:13:51 <xuhanp> thanks, baoli and shshang !
14:14:01 <sc68cal> Shixiong has been sick with the flu, I reached out to him and will probably try to pair up wiht him on his patch
14:14:05 <shshang> well deserved
14:14:21 <sc68cal> It's a big patch - we may want to look into splitting it and passing out the chunks
14:14:22 <shshang> thanks, sc68cal
14:14:32 <shshang> that's a good idea
14:14:33 <sc68cal> that way they can't -1 them all ;)
14:14:44 <sc68cal> hard to hit a moving target ;)
14:15:49 <sc68cal> Do we have any bugs to discuss - or should we go straight into open discussion? I'm really interested to hear baoli's item on the agenda :)
14:15:52 <shshang> :)
14:17:36 <sc68cal> #topic open discussion
14:18:41 <baoli> ok, I am setting up a ipv6 testbed and tried a few things indicated on the agenda
14:21:02 <baoli> I found that I have to use dnsmasq version 2.68 in order to make dnsmasq hand out IPv6 addresses to VMs
14:21:16 <aveiga> that seems odd
14:21:28 <baoli> with ealier version, it says no address available
14:21:30 <sc68cal> Yeah - I think we may need to bump MIN_VERSION for dnsmasq
14:21:32 <aveiga> any particular reason why? I've been using dnsmasq for DHCPv6 for the past 4 years
14:21:49 <aveiga> or was it 3? it's been a long time
14:21:54 <baoli> This is with the static mode
14:21:57 <sc68cal> bug #1233339
14:21:58 <uvirtbot> Launchpad bug 1233339 in neutron "bump dhcp.Dnsmasq.MINIMUM_VERSION" [Medium,Triaged] https://launchpad.net/bugs/1233339
14:22:44 <shshang> the default is 2.66, right?
14:22:46 <baoli> I think that the earlier version works if it's the dnsmasq that allocates the address
14:23:00 <sc68cal> shshang: default is determined by the distro
14:23:20 <shshang> I see. I am using Ubuntu 13.04
14:23:21 <sc68cal> but I think we put a floor at 2.59, which is the MINIMUM_VERSION variable
14:23:31 <baoli> I am runing ubuntun 13:10, and yes, 2.66 is the default
14:23:42 <aveiga> that makes sense
14:23:59 <sc68cal> aveiga and I are on 12.04 LTS
14:24:04 <shshang> I did the same thing, download 2.68 and compile it on my network node
14:24:19 <dzyu> dnsmasq 2.66 still have some problem about support SLAAC mode, I verify it in dnsmasq 2.68
14:24:21 <sc68cal> we might need to check what cloud-archive PPA distributes
14:24:42 <dzyu> dnsmasq 2.68 work well
14:24:46 <aveiga> dzyu: what issues in particular?
14:25:26 <aveiga> SLAAC should work just fine
14:25:48 <dzyu> in dnsmasq log, it can not support stateless and ra-only mode
14:25:56 <baoli> aveiga, yes, slaac works with earlier version
14:26:26 <dzyu> yes, it said it can work, but I found this problem
14:26:26 <aveiga> slaac or stateless? because stateless implies DHCPv6 with the O bit set
14:26:31 <aveiga> and those are conflicting
14:26:53 <aveiga> because ra-only means don't run the dhcpv6 server
14:27:29 <dzyu> ra-only and stateless, dnsmasq will throw error
14:27:45 <aveiga> right, because that's an invlaid config
14:27:56 <aveiga> ra-only and slaac would be the valid config
14:32:25 <dzyu> Ok, thanks for the reminder
14:34:18 <sc68cal> baoli: Do you think you could do a writeup on the ML for what you did for devstack?
14:34:47 <sc68cal> either that - or fork vagrant_devstack and add what you did and add to the chef scripts
14:34:57 <baoli> sc68cal, will do that once I got a chance
14:35:06 <sc68cal> https://github.com/bcwaldon/vagrant_devstack
14:35:36 <baoli> So basically, with some work in devstack and host config, the ipv6 only control network would work
14:36:23 <sc68cal> when you say control network, do you mean the API and management nets, not the network the instances run on?
14:36:44 <baoli> sc68cal, yes. I should say management network
14:37:06 <shshang> management network only?
14:37:23 <baoli> yes, use ipv6 only management network
14:37:46 <xuhanp> baoli, we also tested IPv6 only management network in our Lab. But we are not using devstack
14:38:03 <xuhanp> And we fixed some bugs in glance API and other component.
14:38:03 <sc68cal> was that for all openstack components? That's big news - I know that there was some problems with SQLALchemy connecting to v6 mysql
14:38:18 <sc68cal> that got fixed during this cycle
14:38:33 <baoli> xuhanp, cool. Can you share your experience?
14:39:17 <xuhanp> sc68cal, we opened bugs to sqlalchemy as well. And yes, it got fixed.
14:40:43 <dzyu> python 2.6 have IPv6 urlparse issue, need notice
14:40:48 <xuhanp> baoli, we have our own install scripts for openstack deployment and we are moving to Chef.
14:41:15 <baoli> xuhanp, I see.
14:41:23 <xuhanp> so nothing too fancy. We only try to make everything work by fixing problems we met.
14:41:36 <sc68cal> dzyu: ugh.
14:42:08 <xuhanp> dzyu works on that and he is contributing to Chef. Actually there are several other guys in our team do that too.
14:42:11 <dzyu> openstack commponent support IPv6 management network, I have fixed many such issue, you can search them in Community
14:42:26 <shshang> xuhanp and dzyu, is the big related to the auto-installer, or MySQL?
14:42:30 <baoli> The code seems to be ipv4 centric in terms of setting up config defaults, etc.
14:42:50 <shshang> sorry, bug, not big
14:42:52 <xuhanp> so sc68cal, when you mentioned Chef scripts, I think we are already doing that.
14:43:38 <sc68cal> Gotcha. The vagrant_devstack needs to move to v6 at some point too, but I think we're confined by what VirtualBox supports in host-only networking
14:44:19 <xuhanp> shshang, which bug you are talking about?
14:44:31 <dzyu> about mysql, but have been fixed
14:48:57 <sc68cal> anyone have anything else to discuss? otherwise I can give everyone back 11 minutes
14:49:09 <dzyu> xuhanp: shshang said bug should be sqlalchemy
14:49:13 <shshang> I see. thanks
14:49:49 <dzyu> Currently, openstack should be work well in pure IPv6 network, we have tested in Redhat 6.4.and 6.5, since not via devstack
14:49:55 <shshang> You mean, all nodes communication via pure IPv6, right?
14:49:56 <baoli> dzyu, that's my impression too.
14:49:58 <dzyu> shshang:yes
14:50:06 <baoli> another thing that I saw with shshang's patch was that with slaac mode in the subnet, openstack still allocates ipv6 addresses, and installs iptable rules with those addresses.
14:50:17 <xuhanp> shshang, yes. there can be no IPv4 address on management network
14:50:28 <aveiga> baoli: are those EUI-64 addresses though?
14:50:32 <aveiga> that's intentional
14:50:32 <shshang> xuhanp and dzyu, this is awesome
14:50:56 <baoli> aveiga, no, there are like ::1, ::2, etc.
14:51:03 <aveiga> oh, that's a bug
14:51:08 <aveiga> file it
14:51:24 <shshang> baoli, please let me know the bug id so I can fix it.
14:51:28 <shshang> thanks for bringing it up
14:51:37 <baoli> shshang, sure.
14:51:39 <sc68cal> I think that's because we haven't landed the piece that assigns EUI64 addresses to ports
14:51:59 <sc68cal> which should be addressed by this - https://review.openstack.org/#/c/86044/
14:52:03 <shshang> I thought dzyh's code should be in, right?
14:52:17 <sc68cal> shshang: no, only the part that introduced the ipv6 utils was merged
14:52:41 <sc68cal> the changes to db_base_plugin_v2 were not merged, hence the patch that I just created
14:52:44 <shshang> Oh......I see. That explains.....Let me take a look at my own testbed
14:53:46 <shshang> But still, baoli, please file a bug, or at least send an email to the ML. Let me take a close look
14:53:54 <baoli> This is not external RAs,
14:54:00 <baoli> shshang, sure
14:54:09 <shshang> thanks, baoli
14:54:20 <sc68cal> baoli: yes my commit message needs to fix that
14:54:36 <sc68cal> it's for any time a subnet is configured with slaac or dhcpv6 stateless
14:54:48 <aveiga> baoli: even internal RAs should be doing that, once the patch lands
14:55:32 <baoli> ok, let me take a close look at the patch. and see if that's the issue I was seeing.
15:00:52 <openstack> n0ano: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.
15:01:06 <sc68cal> #endmeeting