15:00:15 #startmeeting neutron_ipv6 15:00:15 Meeting started Tue Nov 18 15:00:15 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:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:19 The meeting name has been set to 'neutron_ipv6' 15:01:10 hi 15:01:19 o/ 15:01:22 hi 15:01:35 Hi 15:01:36 O/ 15:01:54 greetings everyone 15:03:04 dane_leblanc: I saw markmcclain -1'd your spec - let's try and talk with him at some point and figure a way forward for your spec (https://review.openstack.org/98217) 15:03:38 sc68cal: He had 2 comments, one saying that one change should be made as a separate bug 15:04:06 2nd comment was that API changes would depend on the upcoming API splits 15:04:08 sc68cal: they were mostly procedural items 15:04:29 overall we need the work 15:04:57 The separate bug issue is legitimate and easy to fix 15:05:18 i also have spec that needs to be discussed (https://review.openstack.org/129910) 15:06:00 I've created a bug for part of the separation: https://review.openstack.org/#/c/134978/ 15:06:29 It's less clear to me how to line up the spec with the upcoming API changes 15:06:53 we also need to consider https://review.openstack.org/#/c/131145/ 15:07:07 we will be returning errors when someone asks for a FIP for a v6 subnet 15:08:12 raorn: thanks for the link to your spec, I'll take a look :) 15:09:17 sc68cal: there's also related issue - https://review.openstack.org/125061 15:09:23 HenryG: I agree - I think Kilo is going to be a tricky cycle to get features landed 15:10:12 raorn: thanks. That is also on my radar. I have a /27 for v4 and a /64 for IPv6 in my lab - this burns me all the time :) 15:11:43 sc68cal: RE: https://review.openstack.org/#/c/131145/. Talked to Bradley, new patch should be up soon. 15:13:02 baoli: thanks - based on our discussions we had in-person at the summit, as well as talking with markmcclain, the consensus seems to be that floating IPs for IPv6 don't have a good use case at this point 15:13:36 People were using FIPs in v4 as both a way to have public access, and sorta-kina like a VIP for load balancing 15:14:17 so I think that Bradley's patch is the correct way forward until a compelling usecase comes forward 15:14:35 sc68cal: agree 15:15:21 as a consumer of neutron's API I will say that if I have to have two vey different code paths in my tools to support ipv4 and ipv6 chances are good I will not use ipv6 15:16:07 clarkb: The problem is that the API is heavily geared towards the shortcomings of IPv4. 15:16:14 ^ +10000 15:16:16 sure 15:16:26 but I shouldn't need to rewrite everything 15:16:52 clarkb: your tooling should get simpler, due to getting a GUA off the bat 15:16:55 if I want an ipv6 floating IP because it makes tooling simple then why not give it to me? 15:16:58 no it won't be simpler 15:17:03 because it will handle 2 cases instead of 1 15:17:36 we already have to do this massive dance with ipv4 floating IPs. Everything fomr setting up networks and routers properly to actually requesting the IP and attaching it 15:17:45 not needing to do that is good (and I think should be an option) 15:17:58 but if it is the only option I need to do a different dance for ipv6 addrs 15:18:10 which complicates existing tools 15:18:37 Depends on how you are deploying 15:18:46 our tooling is simple, v4 provider network, dual stacked 15:18:47 well I am stuck with what my public clouds give me 15:18:58 tenants attach to that net, boom, all done 15:19:17 also supporting ipv6 floating IPs would be a simple way to add ipv6 addresses to existing hosts right? 15:19:25 No. 15:19:26 anyways, I am just trying to think like a consumer of the api 15:19:27 NO NAT 15:19:44 and no v4/v6 translation 15:19:53 ^ yep 15:19:56 thats fine 15:20:15 but I think the other concern still stands, I will not use ipv6 any time soon if I have to rewrite all my tooling 15:20:26 clarkb: neutron requires specificatoin of --ip-version when creating a subnet. So if you plan to use IPv6, some change might be inevitable. 15:20:30 clouds are supposed to make this easy for me 15:20:47 clarkb: and some clouds _have_ 15:20:48 baoli: ya I think having switches to existing code paths is ok 15:20:55 baoli: but needing new code paths is not ok 15:20:56 like the internal cloud that I happen to be associated with 15:21:38 clarkb, ok, I think I understand your concern. 15:21:48 in the future, hopefully we can do v6 only on a net 15:22:03 so if you want v6, you create a port on that net, and leave this v4 business as it currently stands 15:22:44 actually, we have success with ipv6-only nets 15:22:45 sorry, it's not going to be seamless, since as HenryG pointed out, v4 was baked into the openstack API from day one 15:23:17 so I think the problem with that attitude is clouds exist to make this stuff easier for the consumer of the apis 15:23:31 if that means that we have to deal with a little more complexity in the cloud that is a valuable trade off 15:23:57 If we did consider supporting floating IP for v6, it might require some retooling anyway if the subnet being used is SLAAC 15:24:44 as it stands I already have to special case far too many things that the clouds should just handle for me :) 15:25:18 clarkb: we have FIPv4 today since you can't reach that VM without it, with IPv6 (and a global address) you don't need FIP, so it's one less step, right? 15:25:41 haleyb: its one less step but its a different code path... 15:25:47 I like that simpler is an option 15:25:52 I really think simpler should be supported 15:26:06 but I also think that we shouldn't break a bunch of existing code 15:26:19 what existing code exists for openstack for v6 15:26:23 that we would break 15:26:25 there is none 15:27:02 let's get rid of all the ipv4 crutches people use today so they can run :) 15:27:32 yeah! 15:27:45 haleyb: preach it :) 15:28:00 i've been trying for ~20 years, hasn't worked yet 15:28:15 * sc68cal starts handing out the kool-aid 15:28:39 maybe we need ipv4 patches, like the nicotine ones? 15:29:00 we digress.... 15:29:12 clarkb: I do think that tooling is a valid concern, maybe we can start a thread on the ML to figure out a way forward? 15:29:14 I am just trying to provide an api consumer view point 15:29:35 keep in mind people have to use the api 15:29:39 I think that from the consumer's point of view, the API semantics should be consistent regardless the ip family. I think that's our goal as well. But we may not be able to achieve that 100 percent. 15:29:43 and having tried to use it I think we forget that a lot 15:29:54 baoli: ++ 15:30:01 clarkb: i have non fip-related question for you, as an api consumer 15:30:10 I agree with baoli 15:30:23 baoli: agree 15:30:36 I think we can get pretty close to 100% if we ignore some calls with a warning. 15:30:57 Like FIP :) 15:31:00 HenryG: probably better to just throw an error 15:31:34 sc68cal: I mean like "you asked for a FIP but you already have one" 15:31:39 but v6 will be different since with prefix delegation there will be something like 'neutron subnet-allocate...' 15:32:18 i think carl pushed out his IPAM spec with something like that in it 15:32:23 haleyb: that's for tenants who know what prefixes are and what they want to do with them 15:32:33 haleyb, that will be a new API 15:32:53 haleyb: yeah we're working closely with Carl on IPAM since a lot of his semantics also overlap with IPv6 PD semantics 15:33:03 hoping to re-use code 15:33:52 yes, just that getting a globally-routable prefix is required to really use v6, so there's extra steps as both admin and tenant 15:34:51 For tenants who just want things to work, the defaults should just work. The admin should be the only one who would need to configure or set up something. 15:36:25 If default is giving a tenant router a global prefix that's fine with me, guess it seems a little optional since i might only want a ULA 15:37:49 i now see how this seemingly little api changes could get painful 15:38:09 :) 15:38:49 we'll just have to keep hammering it into shape - right now this all exists in our heads and some pictures on twitter from the whiteboards :) 15:38:56 haleyb: So there is one difference I see in v6. The tenant needs to specify whether their subnet is global or local. 15:39:04 so documentation is a big piece here 15:39:17 ^^ +100 15:39:19 agree - a huge piece in fact. 15:39:51 HenryG: yes, global or local, one get's assigned (from admin pool), the other could be random or user-specified 15:40:26 Do we need to add an agenda item to the mid-cycle to cover any IPv6 work? 15:41:09 Isn't mid-cycle mostly for tech debt and API splits? 15:41:36 I think this one is going to be tech dept and splits 15:41:48 yeah, but i see henry and sean (and myself) are going, so I had hopes 15:42:17 good point - I'm down with an agenda item(s) 15:42:22 haleyb: great, don't forget to add yourself to the wiki 15:42:28 doing it now 15:42:49 too bad there won't be much snow in early Dec 15:44:11 Bring your roller skis 15:44:57 I would like to hear the opinion of the team about the following issue - https://bugs.launchpad.net/neutron/+bug/1393527 15:44:58 Launchpad bug 1393527 in neutron "IPv6 Subnets configured to use external router should not be allowed to associate to Neutron Router." [Undecided,New] 15:45:11 The idea is to stop users from associating a SLAAC subnet (configured to use external router) to a Neutron router. 15:45:21 By doing this, we will be giving an early indication to the user instead of making them wonder why the VM is unable to acquire an IP address. 15:45:47 The mid-cycles have really perfected the "nothing much else to do here, let's get to work" locations. 15:46:05 SridharG: My concern is this would block IPv6 PD 15:47:02 sc68cal: I hadn't thought of that 15:47:17 sc68cal: can you please elaborate.. 15:48:13 It could be that the code that blocks a neutron router to be associated, would have to be un-done when we do IPv6 PD support 15:48:37 it's close enough to the workflow for PD support that it makes me a bit concerned 15:48:51 not 1:1, but close enough 15:49:10 sc68cal, in that case, it's not an external router anymore for the subnet, right? 15:49:48 baoli: to be honest, I'm not quite sure - you may be right 15:49:49 So if the combination indicates use of external router, then it shouldn't be added in to the neutron router. 15:50:13 baoli: yes, thats my point as well. 15:51:03 ugh - I forget what external_router means in the API 15:51:20 external means so many things in neutron :( 15:51:23 SridharG, it's just that the user has to be aware of what each combination means 15:51:25 http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-radvd-ra.html#rest-api-impact 15:51:42 It seems OK but let's watch out that we don't make things awkward for PD. 15:51:56 SridharG: OK - you mean with ipv6_ra_mode NOT SET 15:51:59 ? 15:52:07 sc68cal: yes 15:52:34 ok now I'm getting closer to being on the same page 15:53:19 sc68cal: cool. So the idea is to return an error at an early stage. 15:53:59 Got it now - yes that makes sense 15:54:17 I think I agree with HenryG's thinking. We'll just have to be careful 15:55:02 sc68cal: sure. I'll propose a patch and we can discuss the concerns if any during the review phase. thanks. 15:55:04 With the last 5 minutes - everyone keep an eye on bugs tagged with ipv6 - https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6&orderby=status&start=0 15:56:31 I also want to give folks here a heads up. We are working on an IPv6 + DVR solution here. We have a manual setup for it. We'll share the details soon. 15:57:18 i guess my scpec(s) will be discussed on next meeting? 15:57:38 baoli: rajeev and myself have fixes for this we've been working one, one patch is out already 15:57:57 Would prefer to not have manual setup 15:58:02 haleyb, can you share the link? 15:58:17 raorn: yes, we'll all have to take a look and review 15:58:26 sc68cal, the manual setup is a proof of concept. 15:58:53 ok 15:59:14 baoli: https://review.openstack.org/134676 but i have another to get out as well 15:59:29 haleyb, cool, will take a look at. 15:59:44 our first step is to just get it working, but if you have other thought's i'd like to hear them 16:00:04 great meeting everyone - good to see everyone at the summit. Until next week! 16:00:09 #endmeeting