15:02:28 <sc68cal> #startmeeting neutron_ipv6
15:02:30 <openstack> Meeting started Tue Sep 23 15:02:28 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:34 <openstack> The meeting name has been set to 'neutron_ipv6'
15:03:55 <sc68cal> I think since we're in the RC phase, we can have a short meeting
15:05:07 <xuhanp> sounds great
15:05:34 <sc68cal> If there are any bugs that we need to tag for the RC, please let me know, or reach out to the cores
15:06:21 <xuhanp> sc68cal, I mentioned one during the weekly meeting :-)
15:06:44 <sc68cal> xuhanp: cool! :)
15:08:14 <xuhanp> sc68cal, I tried scapy suggested by you last meeting
15:08:26 <sc68cal> xuhanp: any luck?
15:08:31 <xuhanp> and it works pretty well to send IPv6 neighbor advertisement.
15:08:45 <sc68cal> excellent!
15:09:18 <xuhanp> if we are going that way. we cannot add any dependency on scapy, right?
15:09:32 <xuhanp> just like radvd?
15:10:03 <xuhanp> how can we let deployer know we need scapy for this to work?
15:10:18 <sc68cal> We can add a dependency for it
15:10:40 <sc68cal> probably not in time for Juno, but for K
15:11:36 <xuhanp> in global requirement file?
15:12:21 <sc68cal> probably just in neutron's - http://git.openstack.org/cgit/openstack/neutron/tree/requirements.txt
15:13:07 <aveiga> I don't see the other projects needing to send a custom packet like that, so as sc68cal suggested just keep it in the neutron reqs
15:13:16 <aveiga> making it global is likely to ruffle some feathers
15:13:47 <clarkb> it has to be in global to be in neutron
15:13:51 <xuhanp> OK. I am not so familiar with requirement before. I thought it's for pip install only
15:14:08 <xuhanp> for example, I don't see radvd or dnsmasq showing in the file
15:14:13 <clarkb> and yes for pip installed requirements
15:14:26 <sc68cal> xuhanp: that's because radvd and dnsmasq are not python libraries
15:14:31 <sc68cal> scapy is a python library
15:14:42 <xuhanp> OK. will check that.
15:15:41 <sc68cal> clarkb: thanks for the info
15:19:26 <sc68cal> if there is no other business I'll end the meeting
15:20:07 <xuhanp> sc68cal, I have one more quick question for extra dhcp opts
15:20:18 <xuhanp> since this is left from dhcpv6 BP
15:20:55 <sc68cal> sure
15:21:04 <xuhanp> the problem was we need to specify extra dhcp opts for v6 and v4 since one port can have both v4 and v6 address. If everyone remembers this.
15:21:19 <sc68cal> yep, I remember now
15:21:31 <xuhanp> My plan is to add one prefix to the opt value
15:21:45 <xuhanp> sorry option name
15:21:56 <xuhanp> like:  v6:dns-server
15:22:03 <xuhanp> instead of dns-server
15:22:15 <xuhanp> in this way we don't need to change the API format
15:22:27 <xuhanp> but I would like to hear your comments on this.
15:22:49 <xuhanp> since user need to specify v6 or v4 for each opt now.
15:23:34 <xuhanp> another option is changing the API format to extra_dhcp_option：{
15:23:34 <xuhanp> 'ipv4':{list_of_opt_dicts},
15:23:34 <xuhanp> 'ipv6':{list_of_opt_dicts},
15:23:34 <xuhanp> }
15:23:54 <sc68cal> ^ I think that is probably more clear
15:24:03 <xuhanp> the second one?
15:24:06 <sc68cal> yes
15:24:34 <xuhanp> do we need backward compatibility for API
15:24:47 <xuhanp> I am not sure if I can just go ahead and change that.
15:25:00 <sc68cal> If they don't specify the ipv4 key, and just send values
15:25:07 <sc68cal> then stick it in the ipv4 key
15:25:21 <sc68cal> to preserve backwards compat
15:25:31 <xuhanp> you mean treating IPv4 as default?
15:25:45 <sc68cal> yeah - would that work
15:25:46 <sc68cal> ?
15:26:02 <xuhanp> so those opts will not applied for IPv6?
15:26:21 <xuhanp> then we need to do a lot of checking like if IPv6 is the only address on this port, ect..
15:26:28 <xuhanp> ect -> etc
15:26:30 <sc68cal> yep.
15:27:00 <xuhanp> Oh. maybe we can use the ML to discuss this to gather more opinions.
15:27:04 <sc68cal> not fun, but they didn't think of dhcpv6 when they made the api
15:27:13 <xuhanp> yep
15:27:19 <xuhanp> I agree the second one is much more clear
15:27:32 <sc68cal> ML sounds like a good idea
15:27:45 <xuhanp> sounds good. I will make a discussion then
15:29:44 <sc68cal> anything else to discuss?
15:36:54 <sc68cal> ok everyone, thanks for attending
15:37:01 <sc68cal> #endmeeting