14:00:11 #startmeeting neutron_ipv6 14:00:12 Meeting started Tue Apr 15 14: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. 14:00:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:16 The meeting name has been set to 'neutron_ipv6' 14:01:22 hi 14:01:26 hi 14:01:42 hello all 14:01:44 #link https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_April_15th today's agenda 14:01:45 hello 14:02:51 Sorry for the late e-mail announcing the agenda - but in the future if you know there is a topic you want to discuss - feel free to create the heading line in the wiki 14:03:52 #topic blueprints 14:04:12 do we have any new blueprints to discuss? 14:04:45 sc68cal, as I eluded last time, I'm setting up ipv6-only management and data network 14:04:45 If not - we'll continue on 14:05:13 so I may need a blueprint for that 14:05:15 baoli: OK - please do document it as you progress - either on the openstack wiki or the e-mail list? 14:05:22 baoli: do you want to do that as a BP or a bug set? 14:05:31 you might get more traction in reviews if it's a patch to a bug 14:05:37 I know there is a bug in Nova that is lurking in the background for when you launch an instance with no ipv4 address 14:05:42 sc68cal, sure. I'm still experementing 14:06:08 sc68cal, I added IPv6 snooping to the RA guard blueprint. I saw some similar work going on in IPv4 side. 14:06:34 and we may want to leverage Nachi's vif_security port attribute 14:06:37 xuhanp: perfect. By the way tested your sec-group patch in our lab, for the subnet gateway 14:06:49 and works perfectly 14:07:02 Hopefully, I can get something ready for a proposal this week if a bp is needed. 14:07:04 sc68cal, that's great! thanks for the information 14:07:14 #link http://git.openstack.org/cgit/openstack/neutron-specs/ Neutron blueprints git repo 14:07:42 I think there is a github mirror too 14:08:30 any other blueprints to discuss? 14:08:49 I will probably be adding blueprints in the next few weeks and submitting to gerrit 14:09:04 for work that I've been doing, to get the party started ;) 14:09:42 sc68cal, should we move the existing BP to the gerrit now? 14:09:52 has it opened? 14:10:11 is the BP for work that has been completed or is in progress? 14:10:45 in progress or not started 14:11:16 I think it's worth considering - but I think we're probably still ahead of everyone else in considering. I'm just an enthusiastic early adopter 14:11:26 so use your own judgement for now 14:12:11 but don't forget - if you get a bp accepted (merged) you get ATC 14:12:17 and stackalytics cred ;) 14:12:42 LOL. I only saw one submitted: https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z 14:13:30 ah, so yes looks like they're gearing up 14:13:37 * sc68cal just added a +1 ;) 14:15:21 what is ATC? :D 14:15:31 Sorry for my ignorance 14:15:40 active technical contributor 14:15:47 means you get free tickets to the summits 14:16:25 more importantly it meas the community recognizes you as actively participating in a techical fashion 14:16:33 Hi there, sorry, just finished another meeting. 14:16:47 Oh, I see 14:17:05 zigo: welcome 14:17:17 speaking of summit, I will drive down to ATL in May. Anybody here goes there too? Maybe we can have a real party? 14:17:33 aveiga and I are presenting at the summit 14:17:34 Shixiong: I hope to be there yes. 14:17:34 It is good to have some face time 14:17:49 I will be there 14:18:08 (look for the one guy wearing Debian cloths, and it will probably be me...:P) 14:18:09 sc68cal and aveiga, you two have a speaking session there, right? 14:18:11 Unfortunately I cannot join :-( 14:18:12 I also have registered design summit time too 14:18:33 I have planned to be very available at the summit to do in-person chats 14:18:46 sc68cal: A design summit time for IPv6 discussions? Awesome! 14:19:49 #link http://openstacksummitmay2014atlanta.sched.org/event/71e17f7cebeb80498ddf074e521de981#.U00_8nWAY5I IPv6 in OpenStack Talk 14:19:58 * aveiga ends shameless plug 14:20:07 :) 14:20:36 #topic code reviews 14:21:05 zigo had an e-mail which collected the majority of in-flight patches 14:21:32 sc68cal: Do you think you could work with SridharG to prepare a patch set? 14:21:47 I'm ok to add such a patch set to the Debian Icehouse release. 14:22:11 zigo: I have a patchset that works for icehouse, if you are using an upstream router that does RAs 14:22:21 documentation will be forthcoming 14:22:22 Though I wont be available just right after the 18th (day of the release). 14:22:31 sc68cal: Where can this be downloaded? 14:22:48 we will publish it on the Comcast fork of Neutron on github 14:22:57 sc68cal: I'm working on the patch set for Zigo. Can you share your current patch set for upstream router? 14:23:02 sorry - was using the royal "we" - I mean I 14:23:10 sc68cal: I would like to have a *patch set*, not just a github URL to clone from. 14:23:50 zigo: I understand. Github has a way to create patch sets from URLs - so my plan was to do a compare URL and tack on a .patch to it 14:23:54 So that I can keep each individual patch within debian/patches, with the Debian DEP3 patch header containing the Origin: upstream, http://review.openstack.org/ fields, so that I can *track* patches and eventually update them. 14:24:02 zigo: 14:24:04 ok 14:24:10 then keep an eye on this one 14:24:20 https://review.openstack.org/#/c/64578/ 14:25:15 I think it might be good to point out that such a patchset wouldn't be officially supported as OpenStack hasn't accepted the majority of these patches as valid yet 14:25:15 but this stuff is highly experimental at this point 14:25:27 +1 to what aveiga says 14:25:41 so I'm not sure if you want to fold this into the debian package of openstack 14:25:45 sc68cal: Frankly, I wont have time to work on the patchset myself, but it'd be great if you guys could work it out with SridharG. 14:25:53 I agree. 14:26:16 But what should be done is make sure I get backports of *features* which will be there for Juno. 14:26:27 So that, from a user point of view, we have continuity. 14:26:51 zigo: OK. Can either you or SridharG or Sylvian (sp?) help develop? 14:27:09 we have a lot of work that needs to be done for Juno and we can always use more devs 14:27:25 I do maintain all of OpenStack packages in Debian, so I don't have time to do actual development, I just do some bug fixes here and there, and don't have time for more. 14:27:35 SridharG and Sylvain can, yes. 14:27:44 SridharG: Can you confirm? 14:27:48 sc68cal: I'm in for any IPV6 development as Zigo mentioned. 14:28:28 perfect. I hope that we can also get Sylvain on board as well 14:28:52 I think the big thing we need to do is help Shixiong break up his patch into smaller pieces 14:29:09 We have a big problem with this line 14:29:09 https://review.openstack.org/#/c/64578/6/neutron/agent/linux/dhcp.py 14:29:13 Line 340 14:29:22 sc68cal, I can also help with the breakdown. 14:29:48 That's where we're going to have merge conflicts - so I was hoping to break that chunk out so that people could just add the switches for the v6 attributes 14:30:31 ok, I can also look into the patch. 14:31:10 #link https://review.openstack.org/#/c/70649/ Shixiong's patch 14:31:12 sc68cal, this sounds like a good plan 14:31:49 sc68cal: I have few questions reg' IPV6, will use the Open Discussion time for the questions. 14:32:16 SridharG: thanks 14:32:50 #topic bugs 14:33:16 any bugs to discuss? 14:33:37 sc68cal, I've opened a small bug for ipv6 mode validation and added you to the review list. 14:33:56 #link https://review.openstack.org/#/c/87435/ 14:33:58 xuhanp: which bug? 14:34:00 xuhanp: ok 14:34:18 right now the ipv6 mode can still be specified when ip version is 4 14:34:27 xuhanp: mind if I follow this as well? I can provide some insight here 14:34:52 aveiga, I can add you to the review. thanks! 14:36:33 Recently there was patch to hide the ipv6 attributes which got merged. 14:36:45 baoli: have you run into any specific bits of the v6-only management layer that aren't working? 14:36:47 does it mean that after code opens for Juno, it would be reverted back? 14:36:52 I was wondering if it would be good to tag them as bugs 14:37:05 SridharG: it's there because the attrs exists but don't have backing 14:37:16 it will be reverte for Juno once we provide the functionality 14:37:25 aveiga, I didn't try neutron meta-data which most likely not working 14:37:36 ok 14:37:38 aveiga: aah ok. Thanks. 14:37:55 I think it might be a good idea to mark them as bugs. Maybe others can pick up some of the fixes if they're against other projects 14:38:05 also the code has a better chance to merge as a bugfix 14:38:14 aveiga, I used devstack, so some changes are made there to make the configuration right 14:38:21 ah 14:38:33 I'd be willing to give this a shot in a prod-like lab 14:38:50 if you had specifics in that config, can you publish them? 14:38:59 +1 - please do pubilish them 14:39:43 aveiga, I was about to mention that I'm going to push the changes in devstack as a WIP patch for now. hrzbrig is asking for it from IRC 14:40:02 baoli: awesome - I'll +1 it :) 14:40:08 great! 14:40:19 sc68cal, aveiga, thanks 14:40:41 I have a branch of DevStack that we use for the lab 14:40:58 https://github.com/sc68cal/devstack/compare/upstream_slaac 14:41:40 need to update it to pass in the lla gateway - thanks to xuhanp ;) 14:42:54 sc68cal, will take a look 14:42:58 #topic open discussion 14:43:20 May i know what is the current status of FWaaS w.r.t IPV6? 14:43:43 excellent question - to which I have no idea 14:44:13 I know that security groups for v6 works fine - so hopefully the same thing for fwaas 14:44:28 I don't know if they've really looked at it yet 14:44:43 but if they take the same inputs from neutron like port, and host address, it should be ok 14:44:53 we pass the addr as a string in json 14:45:04 and we are properly building the address at this point 14:45:34 aveiga: true. Security Groups for V6 looks good. 14:46:05 I have a question regarding Floating IP addresses. Since we will not be doing any NAT for IPV6 addresses and the GUA generated by clients (via SLAAC/DHCPV6) can be directly used by the clients as Public IPs, is floating ip address support required for IPV6 addresses? 14:46:22 we currently don't support it 14:46:28 we're mulling over methods to do so 14:46:43 I think it might be worth discussing on the mailing list 14:46:46 there might still be a need for a statically-reserved address space for some systems, so we need to get there 14:46:56 but at this point we're trying to get basic functionality in first 14:47:37 aveiga: May be for LBaaS kind of features we might need Floating IPs. Does it make sense over there? 14:48:52 #info IPv6 - floating-ip like functionality 14:49:00 let's take it to the ML 14:49:07 there's a lot of different ways to pull it off 14:49:13 sure. 14:52:42 one more question :-) 14:52:57 What is currently possible with OpenStack for IPV6? 14:53:09 that's a big question - could you be more specific? 14:53:14 I could see that we can bring up VMs using Provider Networks with IPV6 - this works. 14:53:29 that's where it ends 14:53:33 what are the other main features we can say that they will be supported in IceHouse 14:53:35 we have no way to issue an RA right now 14:53:40 but SGs work 14:54:09 yeah I agree SG works. 14:54:31 I'm fairly certain config-drive is working with v6 14:54:46 but the actual list of official support right now is nil 14:55:14 FWaaS VPNaaS LBaaS are something to be looked into closely. 14:55:29 we need to finish the basics first 14:55:43 and let's not make the perfect the enemey of the good 14:56:12 aveiga: true. I was just listing areas which can trigger some blueprints in IPV6. 14:56:21 absolutely 14:56:28 we'll need to get them in as well 14:58:16 Alright everyone, I'll give everyone back two minutes 14:58:22 see everyone on the mailing list and next week 14:58:28 #endmeeting