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