14:59:50 <sc68cal> #startmeeting neutron_ipv6
14:59:51 <openstack> Meeting started Tue Dec 16 14:59:50 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:59:54 <openstack> The meeting name has been set to 'neutron_ipv6'
15:00:29 <xuhanp_> hi
15:00:48 <aveiga> hello
15:01:24 <rprakash> I saw IPv6 IPAM approval by Kyle yesterday
15:01:33 <sc68cal> rprakash: link?
15:01:58 <dane_leblanc> rprakash: Subnet allocation for IPAM?
15:02:17 <rprakash> Neutron IPAM
15:02:17 <rprakash> https://blueprints.launchpad.net/neutron/+spec/neutron-ipam
15:03:17 <rprakash> He had put high and later changed to Medium Priority
15:03:39 <sc68cal> Looks like the IPv6 impact section of that spec is a little short, so we'll need to keep an eye on the work
15:04:17 <rprakash> OK sean go with the agenda planned
15:04:25 <xuhanp_> sc68cal, I thought prefix delegation is the IPv6 IPAM part.
15:04:51 <sc68cal> xuhanp_: it probably touches the same areas, along with the subnet allocation spec
15:05:15 <xuhanp_> I see. Thanks for the clarification
15:05:26 <sc68cal> xuhanp_: no problem
15:05:28 <dane_leblanc> Prefix delegation will need to make the other IPAMs aware of assignments, I think
15:05:44 <sc68cal> #topic specs
15:06:14 <sc68cal> dane_leblanc: most likely, but since we didn't get anything in for K we'll have to keep an eye on some of this work and make sure we can use it when we get PD accepted
15:06:32 <dane_leblanc> sc68cal: right
15:06:37 <rprakash> Can you elaborate prefix delegation in lfe cycle part or technology?
15:06:45 <aveiga> I have a question regarding specs and policy: is it acceptable to submit a spec without an assignee?
15:07:14 <sc68cal> rprakash: check out the spec in neutron-specs - it is under review
15:07:22 <sc68cal> aveiga: It is probably bad
15:07:28 <sc68cal> you'll get a -1 most likely
15:07:48 <sc68cal> dane_leblanc: I see that the multiple prefix spec landed, congrats
15:08:14 <dane_leblanc> sc68cal: Thanks. Still a few more patches pending for code.
15:08:15 <rprakash> Also note target is K-3
15:09:25 <sc68cal> dane_leblanc: I also ran into a bug that I'm hoping your code can fix - https://bugs.launchpad.net/neutron/+bug/1401728
15:09:26 <uvirtbot> Launchpad bug 1401728 in neutron "Routing updates lost when multiple IPs attached to router" [Medium,Confirmed]
15:09:38 <sc68cal> since that's blocking dual stack testing at the gate
15:10:27 <sc68cal> it seems similar, at least
15:11:38 <dane_leblanc> sc68cal: Yes, it does seem similar to what I'm adding
15:12:44 <sc68cal> Just quickly, I wanted to link everyone to some tempest test scenarios that landed last week - https://review.openstack.org/#/c/112336/
15:13:46 <sc68cal> It's a huge first step, it's put IPv6 on the radar of the DVR team since they need to pass those scenario tests - i know xuhanp_, baoli, and others have been working on fixes
15:14:02 <sc68cal> I think sridhar gaddam too
15:14:49 <haleyb> bug # 1376325 is kind-of the master bug there
15:15:16 <sc68cal> haleyb: thanks - https://bugs.launchpad.net/neutron/+bug/1376325
15:15:17 <uvirtbot> Launchpad bug 1376325 in neutron "Cannot enable DVR and IPv6 simultaneously" [Medium,In progress]
15:15:37 <haleyb> there's two more patches to land for that, in refactor
15:15:52 <sc68cal> haleyb: very cool.
15:16:19 <sc68cal> Hopefully we can get the devstack-gate patch that enables dual stack landed once we squash the routing bug and dane_leblanc's patches - https://review.openstack.org/#/c/140128/
15:16:20 <haleyb> then we'll find the next bug :(
15:16:31 <sc68cal> haleyb: haha - yep!
15:17:17 <sc68cal> That's really all I had - I'll turn it to open discussion
15:17:25 <sc68cal> if there are no objections
15:18:09 <ihrachyshka> I have one dumb question on the code :)
15:18:17 <ihrachyshka> that one of old patches: https://review.openstack.org/#/c/72252/14/neutron/db/securitygroups_rpc_base.py
15:18:23 <ihrachyshka> look at line 337
15:18:37 <ihrachyshka> shouldn't we 'continue' instead of 'return'?
15:19:08 <ihrachyshka> for me it seems like we don't set RA rules if any ipv4 address is assigned to a port
15:20:00 <sc68cal> ihrachyshka: you might be correct - it looks like order is important - first ip being ipv6
15:20:17 <ihrachyshka> it may be relevant to https://bugs.launchpad.net/neutron/+bug/1402407
15:20:19 <uvirtbot> Launchpad bug 1402407 in neutron "IPv6 Router Advertisements are blocked in secgroups when using radvd based networks" [Medium,New]
15:20:22 <ihrachyshka> that I currently look at
15:20:48 <ihrachyshka> though I still don't have any proof for that ;)
15:21:35 <sc68cal> ihrachyshka: I think it's worth a unit test to see if it fails, put an ipv4 address as the first address for the port, then the IPv6 address as second, see what happens
15:22:08 <ihrachyshka> yeah, thanks. just wanted to check briefly first on whether the hypothesis is not that dumb
15:22:12 <baoli> is that just a spurious check to make sure the ips are ipv6? The ips are collected from select_ra_ips_for_network_ids. seems like that it should be removed.
15:23:06 <ihrachyshka> ah right, so that's not the issue :|
15:23:49 <sc68cal> #topic open discussion
15:24:49 <ihrachyshka> btw I've made radvd config generator use Jinja2: https://review.openstack.org/137656
15:25:53 <sc68cal> ihrachyshka: very nice! yeah that looks a lot cleaner
15:29:49 <sc68cal> ihrachyshka: looks like you have some tempest failures to debug
15:29:59 <ihrachyshka> yes, just saw it
15:30:10 <ihrachyshka> I'll update the patch tomorrow :)
15:34:35 <sc68cal> looks like we have some freenode funkyness happening
15:35:17 <rprakash> yes i see no reponse for some time
15:35:51 <rprakash> any link for tempest failure?
15:36:18 <ihrachyshka> rprakash: that's probably due to my patch, not global, so I don't think you really want to waste your time on that :)
15:36:32 <rprakash> ok
15:37:46 <ihrachyshka> should we wrap up? :)
15:38:23 <sc68cal> I'll give it 2 mintues, see if peolpe rejoin or have anything else
15:38:52 <rprakash> anythin of DB implementation for IPv6 remaining?
15:39:26 <sc68cal> rprakash: there is one thing regarding the DB that we may need to keep an eye on
15:39:47 <rprakash> you mean avoidng duplication/
15:39:52 <sc68cal> https://etherpad.openstack.org/p/neutron-mid-cycle-sprint-dec-2014
15:40:12 <sc68cal> during the IPAM discussion at the midcycle the issue of quota requirements came up
15:40:36 <sc68cal> storing the total # of addresses, as the quota
15:40:53 <sc68cal> which means 2^64 for a single prefix
15:40:55 <rprakash> thanks got it
15:41:21 <sc68cal> # of addresses works fine for v4 - then grows huge when talking about v6
15:41:57 <sc68cal> I have concerns about making new APIs and hand-waving this kind of thing
15:42:14 <haleyb> https://review.openstack.org/135771 was the spec i believe
15:42:56 <sc68cal> ah - which merged.
15:43:11 <sc68cal> :(
15:43:39 <haleyb> I thought ryan/carl updated it, will look
15:43:59 <sc68cal> haleyb: nope, it still mentions # of addresses in the spec
15:44:02 <sc68cal> for quota
15:44:47 <haleyb> Yup, have to ask ryan/carl about that
15:45:12 <haleyb> carl_baldwin: you here?
15:45:30 * sc68cal forsees having to use numpy in the future
15:46:00 <dane_leblanc> I asked if we need a quota for prefixes consumed, I think it was Ryan that responded that the existing quota for subnets was sufficient
15:46:15 <carl_baldwin> hayleyb:  I am here but unfortunately, I’ve got to run to an eye doctor appt.  Could we sync up later today?
15:46:33 <haleyb> sure, just a subnet allocation question
15:48:24 <carl_baldwin> haleyb: sc68cal:  I see the question.  I’ll ping you both later.
15:48:30 <sc68cal> carl_baldwin: thanks :)
15:49:38 <sc68cal> unless we have anything else, I'll go ahead and give everyone back 10 minutes
15:50:00 <rprakash> once you have answers please update quota item in etherpad and will try understand details -Thanks
15:50:25 <rprakash> sure
15:51:09 <rprakash> plese go ahead we can close for the day
15:51:31 <sc68cal> #endmeeting