15:01:13 <sc68cal> #startmeeting neutron_ipv6
15:01:14 <openstack> Meeting started Tue Jan 13 15:01:13 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:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:17 <openstack> The meeting name has been set to 'neutron_ipv6'
15:01:29 <xuhanp> hello
15:01:51 <haleyb> hi
15:01:51 <absubram> o/
15:02:57 <sc68cal> For those that missed the general meeting, the K-2 window is approaching fast
15:03:12 <sc68cal> #link https://launchpad.net/neutron/+milestone/kilo-2 K-2 blueprints
15:03:47 <sc68cal> they're focusing on the high and critical items - but xuhanp I know you have a BP that is set for k-2, how goes progress?
15:04:24 <xuhanp> I already proposed a patch. will be great if it can get some reviews.
15:04:55 <xuhanp> https://review.openstack.org/#/c/136713/
15:06:09 <sc68cal> perfect - I think I looked earlier this morning and saw jenkins failing
15:06:16 <sc68cal> don't know if that was gate bugs or your code
15:06:43 <xuhanp> they are all passed now :-)
15:06:47 <sc68cal> :)
15:07:58 <sc68cal> Is there anything else we have set for K-2? I think I saw one bug that was assigned to K-2 that has ipv6 in it
15:08:11 <sc68cal> https://bugs.launchpad.net/bugs/1323766
15:08:12 <uvirtbot> Launchpad bug 1323766 in neutron "Incorrect Floating IP behavior  in dual stack or ipv6 only network" [Medium,In progress]
15:08:59 <sc68cal> it appears the patch for that issue is stalled - https://review.openstack.org/#/c/131145/
15:09:31 <sc68cal> hmm, that might not be the right patch
15:09:46 <sc68cal> There was another patch that would return an error in the API when someone tried to do a floating IP associate on the v6 side.
15:10:34 <sc68cal> nope sorry that looks like the correct patch
15:10:48 <xuhanp> sc68cal, that's the one
15:11:17 <sc68cal> baoli: does Bradley Jones work for cisco?
15:11:38 <baoli> sc68cal: let me talk to him and find out.
15:12:10 <sc68cal> baoli: thanks. He's probably going to need to take a look at some of the refactoring that carl_baldwin has done on the l3 agent
15:12:15 <sc68cal> and rebase
15:12:33 <baoli> sc68cal, sure
15:12:59 <sc68cal> This is just my gut instinct, but the K-3 window looks like it's going to be a lot of things competing for core reviewer attention
15:13:39 <sc68cal> if you have a BP set for k-3 - I would strongly suggest getting your code done ASAP so you have plenty of time for review
15:14:14 <sc68cal> or at least posting what you have so far for review, so that progress is shown
15:14:52 <sc68cal> or consider retargeting for L series
15:15:04 <sc68cal> mestery: ^
15:15:57 <sc68cal> that's all I have for today, I'll turn it over to open discussion
15:16:00 <sc68cal> #topic open discussion
15:16:49 <xuhanp> sc68cal, I would like to discuss my code review https://review.openstack.org/144943 :-)
15:17:02 <xuhanp> the conclusion is not very clear last time
15:17:51 <sc68cal> ok - I meant to read the logs from last meeting - i know we spoke with HenryG about it
15:18:12 <sc68cal> I don't remember if we concluded that we should change the behavior to uncouple from enable_dhcp
15:18:37 <sc68cal> I don't think we agreed on that, but I could be remembering wrong
15:18:54 <sc68cal> if I am incorrect, my extreme apologies
15:19:23 <xuhanp> sc68cal, understood. I cannot remember if everyone is agree on that as well.  the point I made from last meeting was enable_dhcp is conflict with dhcp-mode slaac or None.
15:20:04 <xuhanp> in which case, dhcp is not "enabled" and there is no need to spawn dnsmasq or create dhcp port.
15:20:21 <sc68cal> agree, it does clash conceptually
15:20:53 <sc68cal> but enable_dhcp has a ton of behavior linked to it, as to how neutron behaves
15:21:25 <sc68cal> and we'd also be introducing different behavior between juno -> kilo
15:21:30 <xuhanp> I proposed a easier change in patch set 1, but got objected.
15:22:07 <sc68cal> i'd rather wait for a magical v3 api to come and fix the inconsistencies between v4 and v6 subnets than try and mess with enable_dhcp too much
15:22:56 <xuhanp> that works for me too especially when I need to fix a lot of tempest fails.
15:23:15 <sc68cal> agree.
15:24:32 <xuhanp> sc68cal, then I may need to roll back to patch set1. It will be great if you can have a look after that.
15:24:38 * HenryG shows up late
15:24:49 <sc68cal> xuhanp: no problem :) - isn't code review fun?
15:25:05 <xuhanp> lol
15:28:13 <sc68cal> I'll keep the meeting going till half past, then give everyone back 30 minutes :)
15:28:45 <HenryG> I am not sure I see a problem with "special" behavior for enable_dhcp just for ipv6 subnets. But I need to think about it some more.
15:29:26 <sc68cal> HenryG: my worry is we already have some complicated logic - don't know if I have the stomach for more complicated
15:29:44 <HenryG> I hear you
15:31:03 <xuhanp> HenryG, can you leave your comments on the review if you have new ideas?
15:31:26 <HenryG> xuhanp: will do, although my time this week is limited
15:31:42 <xuhanp> HenryG, sure.
15:33:18 <sc68cal> ok everyone, until next week!
15:33:42 <sc68cal> #endmeeting