15:01:02 <sc68cal> #startmeeting neutron_ipv6
15:01:03 <openstack> Meeting started Tue Dec  2 15:01:02 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:06 <openstack> The meeting name has been set to 'neutron_ipv6'
15:01:20 <ihrachyshka> o/
15:01:27 <xuhanp> hi
15:01:37 <john-davidge> o/
15:01:43 <rprakash> Just wanted to know if IPV6 in neutron supports Mobile Extension in openstack?
15:01:57 <sc68cal> rprakash: please wait until open discussion at the end
15:02:03 <rprakash> ok
15:02:21 <sc68cal> #topic announcements
15:02:36 <sc68cal> #info Spec freeze deadline is next Monday
15:03:05 <sc68cal> #link https://wiki.openstack.org/wiki/NeutronSubteamCharters#IPv6_team IPv6 subteam charter
15:03:50 <sc68cal> #topic specs
15:04:28 <sc68cal> You'll notice I only put a link to the multiple prefix spec on our charter - I have a lot of concerns about the ipv6 and dvr blueprint, due to it's size and how close we are to the freeze
15:04:38 <sc68cal> so I did not include it in our list of specs that we are tracking
15:05:27 <sc68cal> s/it's/its
15:05:55 <sc68cal> Looks like baoli isn't on
15:06:53 <dane_leblanc> Baoli just joined now
15:06:55 <sc68cal> baoli: not to ambush you as you just joined, but I think your ipv6 and dvr spec is in jeopardy of missing the freeze
15:08:08 <baoli> sc68cal: hi
15:08:37 <baoli> sc68cal: can you clarify?
15:09:24 <sc68cal> your blueprint is very large and encompasses many items that are somewhat related, but large enough they warrant separate specs
15:09:35 <sc68cal> the spec freeze is next Monday - IIRC
15:10:23 <sc68cal> so I worry that it's not going to make the freeze
15:10:24 <baoli> sc68cal, ok, then it needs to be divided up before the deadline, I guess.
15:12:11 <sc68cal> OK - so let's break it up - if anyone has a piece that they want to work on for Kilo, please send an e-mail on the ML or in the existing review for which piece you're taking
15:12:19 <baoli> sc68cal, I'll make that as a priority for this week, then
15:12:32 <sc68cal> #link https://review.openstack.org/136878 Support IPv6 routers and DVRs
15:13:15 <sc68cal> baoli: we should probably just let people take pieces - that'll take the pressure off you
15:13:58 <baoli> sc68cal, a couple of folks here have plans working on some of the pieces.
15:14:04 <baoli> Is xu han here?
15:14:09 <xuhanp> yep
15:14:29 <baoli> xuhanp is working on it as well.
15:14:36 <xuhanp> I am working on creating the qg device on each compute node right now.
15:14:38 <baoli> If I'm not mistaken
15:14:54 <baoli> xuhanp, we need to sync up on that.
15:14:59 <xuhanp> baoli, right.
15:15:10 <xuhanp> I will leave comments to your spec review.
15:15:25 <sc68cal> OK - my suggestion is to break it up into separate peices so that no sync is needed - we have less than a week to get a spec submitted, reviewed, and merged
15:15:35 <baoli> xuhanp, sounds good. Do have some time after the meeting to discuss on IRC a little bit?
15:16:26 <sc68cal> I would also suggest picking something *small* and reasonable, there's going to be a ton of changes to the plugins, API layer, etc.. you're going to be dodging merge conflicts a lot this cycle I think
15:16:42 <sc68cal> let's pick small, winnable battles :)
15:16:50 <xuhanp> baoli, it's a little late for me after the meeting. I will ping you to discuss the time.
15:17:05 <baoli> xuhanp, sure.
15:17:14 <absubram> please include me too xuanhp :)
15:17:19 <ihrachyshka> sc68cal: any free battles for someone willing to get involved? I would be interested in one.
15:17:46 <sc68cal> ihrachyshka: keep an eye on the bug queue - i'll link to it in a few minutes
15:17:49 <baoli> sc68cal, yeah, that's the concern. But I think that's something we have to cope with.
15:18:22 <baoli> sc68cal, but I'd like to see a working prototyping system that we can evolve on, and eventually merge to upstream.
15:19:56 <sc68cal> I agree in principal, but my experience with the QoS API extension, which had small changes to just the OVS agent taught me the folly of not keeping up with upstream
15:21:06 <sc68cal> #topic bugs
15:21:22 <xuhanp> sc68cal, how about the extra dhcp opt blueprint for IPv6, can it be made into the charter?
15:21:24 <sc68cal> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6 IPv6 tagged bugs in Neutron
15:21:30 <xuhanp> sorry to interrupt the bugs topic
15:21:36 <sc68cal> xuhanp: no problem.
15:21:39 <sc68cal> #undo
15:21:40 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x3cc0e50>
15:21:43 <sc68cal> #undo
15:21:43 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3db0810>
15:22:05 <sc68cal> xuhanp: do you have a link to your spec
15:22:21 <xuhanp> yep. https://review.openstack.org/129118
15:22:55 <xuhanp> it's pretty trivial.
15:23:15 <sc68cal> reviewed - you'll need to rebase
15:24:31 <xuhanp> sc68cal, will do
15:24:48 <sc68cal> so my comments for baoli's spec also are for this one, deadline approaching, time to review, merge, etc... is low
15:25:49 <sc68cal> Don't forget everyone, I'm not core, I can't +2 specs. I'll try my best to get cores to look and approve but make sure you're also reaching out to cores too
15:25:53 <xuhanp> sc68cal, the spec has been there for a while, do you think it still need a lot of time to be reviewed?
15:26:07 <xuhanp> how about I try to ping some cores to ask their ideas?
15:27:02 <sc68cal> xuhanp: that sounds like a good idea
15:27:15 <xuhanp> sc68cal, will adding it to the charter help speed up the review?
15:27:57 <sc68cal> xuhanp: I don't know - my concern is by adding things to that charter - does that mean the subteam is measured against that list, in terms of success
15:28:04 <sc68cal> mestery: ^
15:28:35 <mestery> sc68cal: The sub-team charter is for deliverables in Kilo, which are tracked. Mostly it's because I'm lazy :)
15:28:52 <sc68cal> mestery: thanks.
15:29:11 <sc68cal> So my concern is having deliverables that we're adding a week before the freeze
15:29:55 <sc68cal> mestery: what are your thoughts? we have a couple blueprints that we'd like to get in before the freeze
15:30:44 <mestery> sc68cal: You mean IPV6 specs you're proposing? If they seem doable, and you think your team can deliver them, lets add them in.
15:30:47 <mestery> sc68cal: Make sense?
15:31:14 <sc68cal> mestery: thanks - that makes a lot of sense
15:32:00 <sc68cal> xuhanp: I'll take a look at your dhcp opts spec, it sounds like a reasonable goal
15:32:26 <xuhanp> sc68cal, thanks!
15:33:11 <sc68cal> #topic bugs
15:33:24 <sc68cal> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6 IPv6 tagged bugs in Neutron
15:33:59 <sc68cal> ihrachyshka: That's probably the best way to get started, find an unassigned bug and start digging
15:34:08 <ihrachyshka> sc68cal: will do :)
15:35:24 <sc68cal> raorn isn't on, hopefully he reads the logs - he's been reporting some bugs and proposing fixes - kudos
15:35:51 <sc68cal> https://bugs.launchpad.net/neutron/+bug/1398380
15:35:56 <uvirtbot> Launchpad bug 1398380 in neutron "DHCP Agent always releases ALL IPv6 leases" [Undecided,In progress]
15:36:58 <sc68cal> hmm, second time this meeting i've mentioned someone and then they join
15:37:22 <sc68cal> raorn: we were just discussing your dhcpv6 leases & brackets bug
15:37:49 <raorn> hi ;-) sorry, i'm late
15:38:25 <raorn> great!
15:39:12 <sc68cal> does anyone else have bugs to discuss?
15:40:58 <sc68cal> OK - I'll go ahead and turn over to open discussion if there are no objections
15:41:22 <sc68cal> #topic open discussion
15:42:53 <ihrachyshka> sc68cal: I have a question on how we spawn radvd. we use ProcessManager. it waits for exit from radvd to proceed. Does it mean we effectively block router updates for the router?
15:43:24 <sc68cal> baoli: ^
15:43:49 <sc68cal> I think we sigkill the radvd process when we do an update to the config file
15:43:52 <ihrachyshka> sc68cal: I experience that behaviour in my setup, though I need to admit it's not clean u/s devstack installation
15:45:00 <baoli> ihrachyshka: I don't quite get your question.
15:45:16 <ihrachyshka> sc68cal: I mean, we invoke radvd with execute() which calls .communicate() on process pipe, meaning it waits for exit of the process. and _spawn_radvd_... thing is called from process_router()
15:45:54 <ihrachyshka> baoli: so doesn't it mean that process_router() will hang until radvd actually exits and returns its output and return code to execute()
15:45:55 <ihrachyshka> ?
15:46:21 <baoli> ihrarchyshka, I don't think so. But I'll have to check to be sure.
15:46:41 <baoli> radvd should be running all the time.
15:47:00 <ihrachyshka> baoli: ok, let's discuss it off the meeting
15:47:06 <baoli> sure
15:47:08 <sc68cal> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/linux/external_process.py
15:50:54 <raorn> about dhcp_release and brackets... i'm not sure if ipv6 addresses should be completely ignored
15:51:36 <raorn> dhcp_release does not support ipv6, but it doesn't seem to complain about it very much
15:52:29 <raorn> on the other hand - checking address family during parsing of dnsmasq hosts file will show the process
15:53:32 <sc68cal> raorn: I'd have to do some code reading to catch up
15:55:32 <raorn> address family check should be added in _release_lease() method, in case there will be working dhcpv6_release some day
15:55:49 <raorn> but that's another issue
15:57:19 <sc68cal> raorn: gotcha. Like I said I don't remember much of the dhcp part of the code at the moment, I need to grab your code and run the unit tests and poke it a bit
15:57:51 <sc68cal> although with that, we're pretty much out of time - see everyone next week!
15:58:05 <sc68cal> #endmeeting