13:59:39 <sc68cal> #startmeeting neutron_ipv6
13:59:40 <openstack> Meeting started Tue Jun 17 13:59:39 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:59:44 <openstack> The meeting name has been set to 'neutron_ipv6'
13:59:50 <sc68cal> Hello all
14:00:09 <HenryG> o/
14:00:16 <aveiga> o/
14:00:17 <xuhanp> hello
14:00:21 <carlp> Morning
14:00:30 <dane_leblanc> hello
14:01:07 <sc68cal> So yesterday kyle and mark conducted a meeting about ipv6 features for juno
14:01:35 <sc68cal> I put some notes down from the meeting, so I'll give people some time to go through it and digest
14:01:39 <sc68cal> https://wiki.openstack.org/wiki/Network/Meetings#IPv6_.28sc68cal.29
14:01:51 <BrianB_> hi
14:04:41 <sc68cal> So the main change in the roadmap is that cores do not want to put support for RAs in Neutron via dnsmasq
14:05:08 <sc68cal> instead, they would prefer that support for RAs be developed using radvd
14:05:46 <HenryG> The radvd blueprint is https://blueprints.launchpad.net/neutron/+spec/neutron-ipv6-radvd-ra
14:05:57 <HenryG> I hope to have a spec filed for it by tomorrow
14:06:35 <aveiga> thanks, HenryG
14:06:44 <aveiga> leet me know if you need any help with it
14:08:59 <sc68cal> So what's everyone's thoughts?
14:10:26 <carlp> I think radvd is better than dnsmasq in this case
14:10:34 <aveiga> +1
14:10:34 <xuhanp> sc68cal, how to deal with the spec I just wrote?
14:10:36 <dane_leblanc> I think RADVD is a better approach, less hacking from what I can tell
14:10:50 <aveiga> radvd provides more support for things like unicast RA, as well
14:11:22 <haleyb> Is there plans to add dnsmasq support later?  i guess i (eventually) saw it as a way to save a namespace - i.e. router namespace where dnsmasq lives for v4 and v6, and also save another process running, since there's one per network
14:11:34 <haleyb> but i'm fine with it for now
14:12:21 <aveiga> the namespace isn't directly connected with the RA daemon choice
14:12:31 <aveiga> if it's radvd or dnsmasq, they still have to have a qrouter namespace
14:12:52 <haleyb> right, but if dnsmasq moved into the qrouter namespace we could remove the qdhcp
14:13:15 <haleyb> we have lots of namespaces on production nodes
14:14:29 <sc68cal> I don't know if that would be possible thoug
14:14:51 <sc68cal> since Neutron still creates the q-dhcp NS for dhcp for v4
14:15:43 <haleyb> it might not be today, i see it as future work, i wasn't around when the decision to have both a qrouter and qdhcp namespace was made, i would have maybe chosen just one
14:16:15 <aveiga> haleyb: I'm concerned though that radvd will still be necessary for advanced features when we get that far
14:16:24 <aveiga> my proposal for flaoting IPv6 requires unicast RA
14:17:03 <aveiga> dnsmasq will not be adding support for it, per http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2012q3/006262.html
14:17:48 <haleyb> i'm fine with radvd as i actually understand it's syntax better.  i'll read henry's spec and comment there
14:25:25 <sc68cal> xuhanp: regarding your question about your BP for dnsmasq and slaac/slaac config
14:25:43 <xuhanp> sc68cal, maybe I should change that to Stateful DHCP?
14:25:55 <xuhanp> for next steps
14:26:00 <sc68cal> That's a good point
14:26:21 <xuhanp> OK. will try to do that after the RADVD spec comes out.
14:26:26 <sc68cal> and then I guess list the radvd bp as a dependency?
14:26:34 <xuhanp> sc68cal, yep
14:29:11 <sc68cal> If there isn't anything else, I can give everyone back half an hour
14:30:14 <dane_leblanc> I didn't see the multiple prefix BP listed in the minutes for the meeting with the cores.
14:30:18 <dane_leblanc> https://review.openstack.org/#/c/98217/4/specs/juno/multiple-ipv6-prefixes.rst
14:30:51 <dane_leblanc> Just want to make sure that doesn't fall off for lack of interest or priority
14:30:59 <sc68cal> dane_leblanc: feel free to add it to my sub-section
14:31:19 <dane_leblanc> sc68cal, will do, thanks.
14:31:21 <sc68cal> I'll try to get cores to take a look at it
14:32:01 <sc68cal> I know i'm nit picking you on the rst syntax, I'll try and post a patch to better explain how to do hyperlinks in rst
14:32:56 <dane_leblanc> I think what I use is an alternate approach, I'll add a response, but I'm open for suggestions.
14:33:14 <sc68cal> Sure - it's just that currently it doesn't render to HTML very well
14:33:36 <sc68cal> some of the links in the references section are broken, etc.
14:34:13 <dane_leblanc> I test it with the online reSt editor (http://rst.ninjs.org/), seems to work fine there.
14:34:40 <sc68cal> That editor has caused problems before
14:34:58 <sc68cal> Where it looks ok in ninjs but does not render the same by sphinx
14:35:07 <sc68cal> dane_leblanc: see - http://docs-draft.openstack.org/17/98217/4/check/gate-neutron-specs-docs/75c8ebf/doc/build/html/specs/juno/multiple-ipv6-prefixes.html#references
14:35:33 <dane_leblanc> That output looks good to me.
14:35:53 <sc68cal> Ref-2 and Ref-3 and Ref-7 are hyperlinks that don't go anywhere
14:36:09 <dane_leblanc> Those have multiple references in the prior text...
14:36:13 <sc68cal> the actual "Ref-2" text
14:36:34 <sc68cal> it creates a link to "http://docs-draft.openstack.org/17/98217/4/check/gate-neutron-specs-docs/75c8ebf/doc/build/html/specs/juno/multiple-ipv6-prefixes.html#id3" which doesn't exist
14:37:06 <sc68cal> so tl;dr is basically ninjs sucks and doesn't render stuff right
14:37:32 <dane_leblanc> Sphinx isn't handling the "citation" syntax...
14:37:35 <dane_leblanc> I'll look into it.
14:38:12 <dane_leblanc> The Ref-2 link should point you back to the prior ref in the doc.
14:40:22 <sc68cal> ok everyone, until next week
14:40:25 <sc68cal> #endmeeting