14:02:35 <sc68cal> #startmeeting neutron_ipv6
14:02:36 <openstack> Meeting started Tue Aug 12 14:02:35 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:39 <openstack> The meeting name has been set to 'neutron_ipv6'
14:02:49 <xuhanp> hello
14:02:58 <absubram__> hi
14:03:02 <HenryG> Hi
14:03:20 <aveiga> o/
14:03:56 <sc68cal> Agenda is pretty light today, I think most of the time can be for just coordinating code review
14:06:42 <sc68cal> xuhanp: how goes the stateful/stateless work?
14:06:58 <xuhanp> sc68cal, I got some interesting comments from baoli
14:07:31 <baoli> Hi
14:07:56 <xuhanp> one is that the extra options of dhcpv6 and dhcp are different, so I am thinking about how to let the code make sense.
14:08:06 <xuhanp> baoli, do you have any suggestions in mind?
14:08:43 <baoli> xuhanp, I was thinking that there might be a couple of ways of dealing with it.
14:09:38 <baoli> xuhanp: when user supplies the extra_dhcp_opts in the port API, is there any verification on if the option is valid?
14:09:47 <baoli> I mean existing verification
14:09:54 <xuhanp> I don't see any verification currently.
14:11:18 <xuhanp> right now it's just name value pairs
14:11:39 <baoli> It used to be ok since it only deals with ipv4. With ipv6 added, would it make sense for the user to indicate if an option is meant for v4 or v6?
14:12:41 <xuhanp> yeah. that will requires API change
14:13:28 <baoli> If you check the dnsmasq definition for the option name strings, same name may be used for both v4 and v6 if the option applies to both.
14:14:05 <baoli> so I think that it will take some thoughts to get it right from user's point of view and implementation point of view
14:14:23 <xuhanp> yep. but if the option involves with v4 or v6 address we should separate them.
14:14:45 <xuhanp> maybe we can think about it and discuss on mail list.
14:16:22 <baoli> xuhanp: sure
14:17:30 <xuhanp> I think the difficult case here is when the port has both IPv4 and v6 address. otherwise, we can just simply use option or option6 for extra_dhcp_opts
14:18:31 <baoli> xuhanp, that's right. But subnet can alos be added after the port is created.
14:18:49 <xuhanp> yep. that makes it even more complicated.
14:19:29 <xuhanp> maybe we can change the format of extra_dhcp_opts name to option:XXX or option6:XXX
14:19:34 <baoli> maybe we can use the name string like v[4|6]:<option-name>
14:19:47 <baoli> xuhanp, looks like we are on the same page
14:20:01 <xuhanp> but we will need to make sure it's backward compatible.
14:20:50 <baoli> v[4|6]: is optional, and by default it's v4.
14:21:18 <xuhanp> sounds like a plan
14:21:34 <xuhanp> I will send a email to list
14:21:53 <baoli> in addition, verification may be needed to make sure that the user provides correct options
14:22:25 <xuhanp> yep
14:22:40 <baoli> cool
14:23:32 <baoli> did you check the file dhcp_common.c? which should help a lot
14:24:03 <xuhanp> not yet. will do
14:26:53 <sc68cal> Very cool.
14:27:39 <sc68cal> I think that J-3 is going to have a lot of stuff trying to land
14:28:15 <sc68cal> so if possible let's try and keep the review cycles short on some of this stuff so we can get cores on it asap
14:30:00 <xuhanp> sc68cal, sounds good. Maybe the extra_dhcp_opts validations stuff baoli and I discussed today can go to a separate patch, so we can get the major part landed first.
14:30:16 <aveiga> +1
14:30:32 <sc68cal> Yeah it sounds like there are lots of gotchas in that
14:30:35 <aveiga> splitting it up makes it less likely for other parts to miss because of nits on one bit
14:31:14 <HenryG> Yes, I can see it being viewed as a separate bug
14:32:03 <baoli> sounds good to me
14:32:46 <baoli> in that case, I'll +1 on this current patch
14:33:08 <sc68cal> very cool
14:33:12 <xuhanp> I will add a TODO or FIXME at your comment place
14:33:24 <baoli> xuhanp, thanks
14:35:31 <sc68cal> xuhanp: I'll also test the patch in the lab at some point just to allay my fears about the host file. Your code looks fine, I just get a little feaful when someone is in that area of the dnsmasq code :)
14:35:44 <pcarver_> The mention of a separate patch brings up a question I have. How are people keeping track of everything that's in flight and what pieces are needed in order to get various parts of IPv6 working?
14:36:19 <sc68cal> pcarver_: the specs that get merged in neutron-specs is what I use to track
14:36:54 <pcarver_> There's a list of code reviews on https://wiki.openstack.org/wiki/Neutron/IPv6 but all the links are broken. Is that info no longer used?
14:37:28 <aveiga> pcarver_: that wiki is way out of date
14:37:38 <sc68cal> pcarver_: it's probably out of date, but it looks like the updated gerrit system broke links too :(
14:37:49 <sc68cal> when they did the upgrade to gerrit
14:38:33 <pcarver_> Would it make sense to either delete it or update it? Right now it's the top Google hit for "neutron ipv6"
14:39:28 <pcarver_> I'd be happy to update it if I knew what to update it to
14:39:59 <pcarver_> Are the list of reviews still accurate if I just search in Gerrit for the correct links?
14:40:43 <pcarver_> Or have some of them been obsoleted and new ones needed that aren't on that list?
14:41:02 <sc68cal> Many of those reviews did get merged, so I think we can remove that section
14:41:29 <sc68cal> Ideally we should add some docs to docs.openstack.org and link from the wiki
14:45:24 <dane_leblanc> Maybe we'll eventually need separate sections for J-release blueprints and upcoming K-release blueprints.
14:49:18 <pcarver_> I'll see what I can do about cleaning up the links on the wiki. My problem is that I still feel kind of fuzzy on where we are at a high level. i.e. what user meaningful functionality we expect in J vs K
14:49:54 <sc68cal> J release will support *all* configurations for the ipv6 modes
14:50:08 <sc68cal> meaning radvd and dnsmasq will be configured properly for v6
14:50:39 <sc68cal> basically the following specs
14:50:49 <sc68cal> http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-provider-nets-slaac.html
14:50:58 <sc68cal> http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-dnsmasq-dhcpv6-stateless-stateful.html
14:51:04 <sc68cal> http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-radvd-ra.html
14:52:41 <pcarver_> ok, I'll take a crack at updating the wiki and see how it goes.
14:54:17 <sc68cal> pcarver_: thanks
14:56:37 <sc68cal> Do we have any other business? Otherwise I'll give everyone back a couple minutes
14:57:05 <dane_leblanc> I put some code up for review.
14:57:09 <dane_leblanc> https://review.openstack.org/#/c/113339
14:57:44 <dane_leblanc> Blueprint is still in limbo, not -1 or -2'd, but no response for feature exception freeze
14:58:46 <sc68cal> Having the code posted, I think that'll help get it merged early in K
15:00:51 <sc68cal> ok everyone, till next week!
15:01:00 <sc68cal> Doing great work, keep it up!
15:01:05 <sc68cal> #endmeeting