14:02:02 #startmeeting neutron_ipv6 14:02:02 Meeting started Tue Feb 25 14:02:02 2014 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:05 The meeting name has been set to 'neutron_ipv6' 14:02:20 #topic recap last meetings actions 14:02:48 #link http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-02-18-14.00.html 14:03:19 So - the only actions we had for last week was for me to refresh the review 14:03:39 #link https://review.openstack.org/#/c/52983/ 14:03:57 I have a new patchset that adds the validation of combos, and updates the alembic script 14:04:13 seems like we need another upgrade 14:04:43 I plan on pushing it to gerrit today - I just want to make sure I don't have any silly mistakes that forces me to spam gerrit with little fixes ;) 14:04:57 like pep8, etc... 14:05:02 Hi, guys 14:05:47 #topic code review 14:05:56 We have a bit of happy news to report 14:06:10 the neutron VIF hairpin patch has landed in Nova 14:06:18 cool 14:06:20 cool 14:06:23 +1 14:06:24 great! 14:07:11 #info merge window for I-3 is March 4th 14:07:31 that is way too close 14:07:53 I believe the next high priority patch is xuhanp's patch that limits the scope of RAs allowed to ports 14:08:18 sc68cal, is there any way to speed up the current reviews? I also have the client code submitted yesterday based on the two mode design 14:08:59 xuhanp: that's great - do you have a link to the client code review? 14:09:22 yes. #link https://review.openstack.org/#/c/75871/ 14:09:35 Jenkins fails because your code is not merged yet. 14:10:13 for the RA security group patch, I opened a bug and submitted code review to address baoli's comment 14:10:25 but the approach is debatable 14:10:47 #link https://review.openstack.org/#/c/76125/ 14:10:57 xuhanp, I saw that 14:11:16 hope that can speed up the process to address your comment, baoli 14:11:32 xuhanp, maybe marking the other bug as a dependency would get jenkins to pass? https://wiki.openstack.org/wiki/Gerrit_Workflow#Add_dependency 14:12:04 dane_leblanc, I didn't know we can do that for two projects. Can we? 14:12:21 I don't know if it works cross project either. 14:12:23 D'oh, I don't think so. 14:12:39 would be very helpful :) 14:12:59 xuhanp, my only concern is this: the gateway address is used to establish (default) route. But in the case of ipv6, it's used to create a iptables rule which has a specific requirement on the address. 14:13:47 baoli, any suggestion to address this? 14:13:48 xuhanp, maybe it should be explicitly addressed by the security group API? 14:14:04 baoli: do you have a use case where this is an issue? 14:15:13 well, I just felt that it's not a proper way to do so as xuhanp indicated it's debatable 14:15:51 I haven't be able to spend time on the security group api last week. 14:16:01 so for the sake of working v6 in icehouse, can we push it through and file a bug against it to pull it back to SG API for Juno? 14:16:04 My concern is that the -1 is preventing this review from being seen by core 14:16:19 they usually filter reviews that have a -1 14:16:45 I can give a +1 14:17:20 perfect - thank you 14:18:15 Any new blueprints? 14:18:25 Another concern is that the routing guideline/principle requires that the gateway ip is on the same subnet. Does it apply to IPv6 as well? 14:18:43 baoli: I think we covered this before, perhaps on the ML? 14:19:04 Someone brought that up and I showed them the use case of GUA subnet but LLA gateway 14:19:06 baoli, this is allowed if you set the con right. 14:19:07 they were OK with it 14:19:14 con -> conf 14:19:17 yeah, there's a flag to set gateway on link 14:19:23 force_gateway_on_subnet 14:19:37 sc68cal: what's the default value? 14:19:38 but the router interface attach will fail. That's my second link is about. 14:19:45 aveiga, false 14:19:49 ok 14:19:58 thankfully false - I think we have you to partially thank for that aveiga ? 14:20:14 definitely 14:20:21 xuhanp: I think the router attach code might need to be updated. Ideally you'd want the router to have two addresses 14:20:22 I think you were able to slam the breaks on them setting it to true, if I recall correctly the ML thread 14:20:28 one on-link and one LLA 14:20:43 sc68cal: yeah, though I'm not the reason it was already false :0 14:21:27 currently my change #link https://review.openstack.org/#/c/76125/ is just allow LLA be attached to router. 14:21:39 in order for the RA rule to work, the bug xuhanp just submitted need to be approved as well. 14:21:54 so THAT can be set as a dep in gerrit 14:21:59 since they're both neutron 14:22:50 aveiga, you mean I set the security rule to be dependent on my new patch? 14:23:04 set the LLA router as a dependency for the RA filter 14:23:31 OK. I need to check if two addresses works for current code. I doubt that. 14:24:03 so if two addresses are allow, Which one will the dnsmasq be spawned on? 14:24:13 It might be useful to open a blueprint to capture the two addresses on a router interface 14:24:14 should be on LLA 14:24:23 since the RA MUST come from LLA 14:24:33 so shshang's code need to check that? 14:24:42 sc68cal: +1 14:24:56 xuhanp: I don't think so. They should technically be on the same namespace 14:25:32 sc68cal, can we still do blueprints in icehouse? I thought the deadline for blueprints is gone. 14:25:54 you can still add one. We don't necessarily need the GUA on the router at this time 14:26:06 ^ +1 14:26:06 it's recommend to route via LLA anyway 14:26:27 just set it for J 14:26:36 OK 14:28:34 #topic docs & wiki 14:29:30 So, since we're making good progress on the code side of things, we should probably look into updating documentation and the wiki 14:29:57 #link https://wiki.openstack.org/wiki/Neutron/IPv6 14:29:58 I can take a crack at that 14:30:27 the Neutron docs are going to need some serious updating to provide examples and documentation for what we're changing here 14:30:34 +1 14:30:42 +1 14:31:10 I plan to do some developer doc as well 14:31:16 I can take an AI to collect a list of Neutron docs that need changing. I'm going to be away next week, so give me some time to take this one on 14:32:00 aveiga: OK - if you're going to be away we don't have to do an AI, I'll just make it part of our routine 14:32:07 alright 14:32:08 to talk about docs 14:32:45 I don't think I have anything else, so I'm ready to turn to open discussion 14:33:35 #topic open discussion 14:35:52 one more thing about xuhanp's new bug: with neutron subnet-create --ipv6 --gateway LLA, it needs to make sure that the router port is created with the LLA and an Ipv6 address from the subnet. Does it make sense? 14:36:33 baoli: that's what xuhanp was talking about with a BP for two addresses on a router 14:37:06 yeah. Currently, I just allow to make the gateway as LLA and create a port with that. 14:37:28 aveiga, xuhanp, ok. 14:37:32 I am not limiting the gateway port to LLA 14:46:52 xuhanp, I need to take a close look at https://review.openstack.org/#/c/76125/1/neutron/db/db_base_plugin_v2.py. But would that change apply to all the fixed_ips to be added? 14:47:24 it will be apply to gateway attach but not port create 14:47:31 if I checked that correctly 14:48:05 the if else branches are very complicated there. 14:48:58 and I did some tests but not sure if I cover them all. 14:49:26 by port create I mean the "normal" port create. 14:50:01 question here, since I don't fully know how the code works: doesn't namespace creation automatically get you a LLA address? 14:51:24 xuhanp, ok. I might find some time to check on that with your patch 14:52:28 aveiga, you mean the dnsmasq can automatically send RA from qr device's LLA? 14:52:36 aveiga, so far, I have seen that a LLA is automatically assigned with ipv6 enabled on a port. 14:52:52 I'm saying that on port creation for the router, just use the GUA 14:53:03 it's valid, but dnsmasq will still issue the RA from the LLA 14:53:20 and you can use your existing code that derives the LLA for Horizon to set the RA filter 14:53:39 that gets you a GUA on the router creation, but valid LLA-derived RAs 14:53:57 so does the GUA has to be on the subnet's cir? 14:54:02 cidr 14:54:08 yeah, it would be a regular addr 14:54:22 per baoli's request that we have an on-subnet addr for the router in some instances 14:54:25 that I think that will work by the current code. 14:54:27 would still be valid, technically 14:55:48 so will there be an use case that subnet is using regular address and still use the LLA as gateway. 14:56:02 just trying to confirm that my change has a valid use case. 14:56:04 you will always use the LLA as the gateway 14:56:08 that's where the RAs come from 14:56:21 and by gateway I mean default route 14:56:48 oh. Yeah. sorry. I confused that with the router port. 14:57:02 I think it will still work for now 14:57:20 we might need to add a data structure for Juno to keep the LLA stored with the Router data 14:57:26 or derive it when needed 14:57:45 Neutron port objects have the fixed_ip field, which can have multiple entries 14:57:46 it may come up for things like LBaaS and FWaaS 14:57:53 well, there you go 14:58:00 the router port just has an extra fixed for the LLA 14:58:24 dzyu's patch did just that, for the EUI64 addrs 14:59:20 Sadly, we are out of time 14:59:45 Thanks everyone for joining - long live ipv6! 14:59:56 see everyone next week! 15:00:00 thanks! 15:00:04 thanks 15:00:06 see you guys 15:00:23 #endmeeting