15:01:29 <sc68cal> #startmeeting neutron_ipv6
15:01:30 <openstack> Meeting started Tue Feb 10 15:01:29 2015 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:33 <openstack> The meeting name has been set to 'neutron_ipv6'
15:01:40 <aveiga> o/
15:02:02 * sc68cal grabs a cup of coffee real quick
15:05:12 <sc68cal> So last week we got xuhanp 's patch landed for K-2
15:05:30 <xuhanp> thanks for everyone's review!
15:06:45 <sc68cal> #topic blueprints
15:07:12 <sc68cal> #link  https://launchpad.net/neutron/+milestone/kilo-3 Kilo 3 blueprints
15:07:28 <sc68cal> 53 blueprints targeted for K-3. Whew!
15:07:49 <ihrachyshka> sc68cal, a lot of them just failed to merge in their slots
15:08:01 <ihrachyshka> (some of kilo-2 stuff is not even started yet)
15:08:32 <sc68cal> ihrachyshka: agreed - however it always gets chaotic in the last milestone, everyone's trying to get their stuff merged.
15:08:48 <ihrachyshka> ..and half of them fail
15:09:10 <sc68cal> personally I hate the last milestone - I like skipping it and just going for the first of the new release
15:09:26 <sc68cal> Anyway, for those slated for K-3, I salute you!
15:10:23 <sc68cal> #link https://blueprints.launchpad.net/neutron/+spec/ipv6-prefix-delegation IPv6 PD support
15:10:32 <sc68cal> baoli: how goes progres?
15:12:07 <sc68cal> guess he's not on. dane_leblanc, are you online?
15:12:15 <dane_leblanc> sc68cal: Hi
15:12:32 <sc68cal> I saw you pushed a new patchset for your multiple prefix support
15:12:55 <dane_leblanc> Yes, it's still marked as WIP, but I'm going to remove that soon.
15:13:03 <dane_leblanc> #link https://review.openstack.org/#/c/149068/
15:13:14 <dane_leblanc> It's quite large.
15:13:54 <dane_leblanc> I still have some Tempest tests failing (LBaaS), but I'm closing in on getting that running.
15:14:23 <dane_leblanc> There is one earlier patchset that needs a small change after discussing with baoli
15:14:34 <dane_leblanc> #link https://review.openstack.org/#/c/113339/
15:14:46 <sc68cal> Cool, I'll probably sit down and read through it - nice job though, fixing the L3 agent's port structure.
15:14:50 <dane_leblanc> And 2 more smaller patchsets coming, one from dboik
15:14:53 <sc68cal> pain in the rear
15:14:58 <dane_leblanc> Big pain.
15:15:26 <dane_leblanc> It's like fixing plumbing in an old house, touch one thing, and it leads to more bad stuff.
15:16:04 <dane_leblanc> I'm hoping I'm doing the right things in 149068.
15:16:24 <sc68cal> yeah as you know I started poking at it too, basically to catch up to you in terms of understanding, and that's totally true
15:16:57 <dane_leblanc> Yes, I'm glad that we were like minded in what needed to change.
15:16:57 <sc68cal> I think you're totally on the right track :)
15:17:31 <sc68cal> I cheated though because when I got stuck I was like "ahhh, dane_leblanc probably has it all figured out"
15:17:51 <dane_leblanc> :) Gee, thanks.
15:18:46 <baoli> sc68cal: we are making some progress on PD
15:19:58 <sc68cal> baoli: very cool
15:20:14 <baoli> one issue we have is that the dibbler client is not geared to support the cloud environment such as running inside the neutron router. So we have to enhance it.
15:20:36 <sc68cal> baoli: oh? tell me more!
15:21:14 <baoli> Dibbler is designed to run, pre configured, and on a single host
15:21:21 <carl_baldwin> baoli:  I wouldn’t take enhancing a dependency like that lightly.
15:22:14 <carl_baldwin> baoli: The lead time required to get a new version of it in to distributions is pretty large.
15:22:29 <haleyb> +1 took the words out of my mouth :)
15:22:40 <baoli> carl_baldwin, I agree
15:24:12 <baoli> but we are getting closer to have an end-to-end run.
15:24:38 <dane_leblanc> We've chatted about alternatively doing a roll our own simpler version of dibbler, but that's last resort, I think.
15:25:35 <baoli> dane_leblanc, do you mean writing the dhcpv6 client from scratch?
15:25:55 <dane_leblanc> Yes. Minimal, if that's possible.
15:27:24 <sc68cal> having a way to do bit twiddling for ipv6 would be useful - xuhanp needs something like that for NDP proxy
15:27:50 <sc68cal> plus markmcclain and i had an interesting convo way back in atlanta about some crazy ideas :)
15:30:15 <dane_leblanc> baoli, though with only ~3 weeks left, I don't think building from scratch is feasible.
15:32:59 <sc68cal> probably not
15:34:06 <sc68cal> baoli: do you think you could write up your findings and share on the ML? I'd like to know more of the background if possible
15:34:57 <baoli> sc68cal, sure
15:35:39 <sc68cal> just to clarify, it's when it's running as a client, or a server that you're seeing issues?
15:36:27 <baoli> sc68cal, we need a client initially that supports PD. We are trying to integrate the server into neutron yet.
15:36:42 <baoli> s/are/are not
15:37:25 <baoli> So the client needs to be able to take new requests whenever they come.
15:38:09 <sc68cal> did you guys evaluate WIDE-DHCPv6?
15:38:40 <baoli> sc68cal, took a brief look at it as well, and it doesn't seem to support that either.
15:39:05 <sc68cal> are you sure? I'm using it on my home gateway to do PD
15:39:35 <sc68cal> I can share configs. I've been sort of meaning to do a writeup on how to do ipv6 home gateways with freebsd
15:39:44 <baoli> sc68cal, do you have to pre configure it? what happens when you try to change the configuration?
15:40:33 <sc68cal> baoli: Here's the client config for PD - https://gist.github.com/sc68cal/73c29b55e05281a0b44c
15:41:01 <sc68cal> it just specifies which interface to send the PD on, and which interface to add the PD to
15:41:23 <sc68cal> so em0 is my gateway port, alc0 is my LAN port, pretty much what we're looking to do on the neutron router
15:42:20 <baoli> sc68cal, the issue is how to change the config when change occures in the router, so that the client can take proper actions.
15:43:06 <sc68cal> I think all you'd need to do is SIGHUP wide-dhcp6c so it sends another PD request
15:43:36 <baoli> sc68cal, I checked the doc, and it says that the existing lease will be released with SIGHUP
15:43:59 <sc68cal> when you say config changes ooccur, like what kinds of config changes?
15:44:01 <baoli> sc68cal, so although it support SIGHUP, it doesn't do what we need to do.
15:44:42 <sc68cal> address changes?
15:44:43 <baoli> sc68cal, subnet for PD is added at run time, and it can happen any time.
15:45:39 <sc68cal> right, but there is some interaction between the Neutron server and an API user that would cause that address change, right?
15:47:45 <baoli> sc68cal, each pd-enabled subnet needs a prefix from the delegating server, right?
15:48:10 <sc68cal> baoli: correct
15:52:25 <sc68cal> baoli: is there more? I'd like to catch up to you guys in understanding
15:53:18 <baoli> sc68cal, that's all, basically we need to enhance the client so that it can support dynamic requests. without it, we can have very limited functionality initially.
15:55:33 <sc68cal> when you say dynamic requests, do you mean if the prefix being delgated to the neturon router changes?
15:55:53 <sc68cal> or something else?
15:56:57 <haleyb> i thought with dibbler you could request the prefix too
15:57:23 <baoli> sc68cal, I'm not sure we are on the same page. Do you mean to say that one neutron router needs one prefix only?
15:58:35 <sc68cal> yeah, we may not be on the same page - maybe we should do a phone call to help me understand more :)
15:59:22 <SridharG> team, please review the following patch and share your views "reg: changing the exception from TypeError to ValueError". Thanks.
15:59:23 <SridharG> https://review.openstack.org/#/c/137774/9/oslo_utils/netutils.py
16:00:06 <sc68cal> SridharG: will do
16:00:12 <sc68cal> looks like that's all the time we have
16:00:17 <sc68cal> until next week!
16:00:19 <sc68cal> #endmeeting