15:00:11 <sc68cal> #startmeeting neutron_ipv6
15:00:12 <openstack> Meeting started Tue Oct 14 15:00:11 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:15 <openstack> The meeting name has been set to 'neutron_ipv6'
15:00:44 <john-davidge> o/
15:01:25 <xuhanp> hi
15:01:33 <sc68cal> https://wiki.openstack.org/wiki/Juno_Release_Schedule
15:01:48 <sc68cal> later this week is the official juno release
15:02:19 <sc68cal> I'd like to commend everyone on the work that was completed this cycle - everyone has done a fine job
15:03:54 <sc68cal> just a bit of housekeeping, if there are bugs that missed this release that you believe should be incorporated, please work on them and propose them to be backported
15:04:04 <sc68cal> after they are merged in K
15:04:50 <sc68cal> Last week we merged an API change - for J it is not possible to update the ipv6_*_mode attributes after the fact
15:05:09 <sc68cal> there are issues with it, and we plan to try and address this coming cycle
15:06:53 <sc68cal> https://bugs.launchpad.net/neutron/+bug/1362966
15:06:54 <uvirtbot> Launchpad bug 1362966 in neutron "IPv6 two attributes cannot be updated to None" [Medium,In progress]
15:07:56 <sc68cal> also tracked in https://bugs.launchpad.net/neutron/+bug/1378952
15:07:57 <uvirtbot> Launchpad bug 1378952 in neutron "Updating ipv6 modes is problematic" [High,Fix released]
15:08:50 <sc68cal> Also, neutron-specs has been updated for people to file specs for the K cycle
15:09:28 <xuhanp> sc68cal, I planned to file one spec for extra_dhcp_opts which discussed here before
15:10:07 <sc68cal> xuhanp: sounds good - we got consensus on the ML on the way forward with that, if I remember correctly.
15:10:22 <xuhanp> sc68cal, yep
15:10:33 <sc68cal> xuhanp: not so much on the HA for ipv6 and ND packets though
15:10:59 <xuhanp> Mark reminded me that we cannot use scapy because of the license
15:11:28 <sc68cal> yeah... bummer :(
15:11:29 <xuhanp> So I searched around and found that ryu also has utility to send out ICMPv6
15:11:38 <sc68cal> http://lists.openstack.org/pipermail/openstack-dev/2014-October/048373.html
15:11:40 <xuhanp> not sure if we can use that.
15:12:31 <sc68cal> I'm not sure either
15:13:00 <xuhanp> let's wait for community's feedback then
15:13:07 <sc68cal> xuhanp: agreed
15:14:46 <sc68cal> john-davidge: how goes the devstack patch?
15:15:44 <john-davidge> sc68cal: I pushed a new patch set up earlier today to adress the comment about documentation https://review.openstack.org/#/c/87987/
15:16:03 <john-davidge> Reviews appreciated! :)
15:16:06 <sc68cal> I'm not sure I agreed with that -1. To be honest devstack's docs are awful
15:16:16 <sc68cal> and is a bigger issue than just your review
15:16:27 <sc68cal> not fair to punish you for it
15:16:45 <amotoki> xuhanp: (maybe a bit late) i saw your mail on ryu library. Does ryu provide a python library for packet generation or is ryu library a full stack?
15:17:02 <john-davidge> sc68cal: Haha, agreed! But a little extra documentation never hurt anybody. Either way I've already made the changes. Hopefully someone will find them helpful.
15:17:05 <HenryG> xuhanp: Have you looked at ndsend?
15:17:20 <HenryG> http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html
15:17:20 <amotoki> I can clarify their policy on python libraries.
15:17:37 <sc68cal> HenryG: we discussed in previous meetings
15:17:44 <sc68cal> the problem with that binary is it's part of openvz
15:17:52 <xuhanp> amotoki, it provides packet generation and we need to use socket to send the packet.
15:18:08 <xuhanp> HenryG, and it's only for ubuntu as far as I know
15:18:17 <amotoki> xuhanp: is it a separate module from the ryu main module?
15:19:11 <xuhanp> amotoki, it's ryu.lib.packet
15:19:17 <xuhanp> not sure if it's from the main module
15:19:22 <amotoki> ryu itself is the library for openflow controller and I am afraid we add a whole library for our dependency.
15:19:47 <amotoki> xuhanp: okay. I will reach the authros this week.
15:20:25 <xuhanp> amotoki, I already have some code available about how to construct the packet and send by socket. How to import it is the only concern here.
15:20:45 <amotoki> xuhanp: i think we are in the same page.
15:20:58 <xuhanp> amotoki, sounds great
15:21:33 <amotoki> I just would like to clarify what happens if we have a dependency on ryu.
15:22:03 <xuhanp> understood.
15:22:09 <sc68cal> big dependency for a little feature
15:22:24 <sc68cal> pulling in all of ryu
15:22:28 <amotoki> agree. it is my concern too.
15:24:36 <sc68cal> just googling here
15:24:45 <sc68cal> I see a bsd licensed packet lib
15:24:54 <sc68cal> but no clue if it has what we want :(
15:25:17 <xuhanp> sc68cal, I remember ryu is under apache
15:25:25 <sc68cal> https://code.google.com/p/dpkt/
15:25:36 <sc68cal> has an icmpv6 module
15:26:44 <amotoki> i know ryu team itself has opensource mind and our concern is that we have a big dependency.
15:28:16 <aveiga> xuhanp: I think the concern is less about ryu's license and more  about the amont of code you pull in just to send ND packets
15:28:28 <xuhanp> understood
15:28:49 <xuhanp> also we need to create a new binary for that since we need to call it from namespace
15:29:04 <xuhanp> I didn't see any other example of doing this
15:34:51 <sc68cal> If we don't have any other business, we can push the ryu dependency to the ML and I can give everyone back half an hour
15:38:36 <sc68cal> OK everyone! until next time!
15:38:38 <sc68cal> #endmeeting