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