15:00:13 <sc68cal> #startmeeting neutron_ipv6
15:00:14 <openstack> Meeting started Tue Jan 27 15:00:13 2015 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:17 <openstack> The meeting name has been set to 'neutron_ipv6'
15:01:44 <sc68cal> Kilo-2 milestone is coming up quick
15:02:37 <sc68cal> xuhanp: how goes your dhcpv6 opts review?
15:03:01 <xuhanp> sc68cal, pretty great. Got a lot of comments thanks to everyone
15:03:51 <ihrachyshka> o/
15:03:57 <baoli> Hi
15:04:10 <sc68cal> xuhanp: cool, let me know if there is anything we can do to help
15:04:20 <sc68cal> s/me/us
15:04:48 <xuhanp> sc68cal, will do. thanks
15:05:44 <sc68cal> I'll open the floor - anyone have anything they'd like to discuss?
15:06:14 <ihrachyshka> these days I considered writing some tests for ra.py, and I tried to split tests for the module from test_l3_agent first. it was not trivial and I ended up with the series: https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:split_ra_unit_tests,n,z
15:06:45 <ihrachyshka> I would like people to check whether this smth we should approach (I guess it corresponds to a bp we have to restructure unit tests)
15:07:52 <sc68cal> ihrachyshka: thanks for the heads up - i'll take a look. I like the concept already
15:08:10 <ihrachyshka> the main one (and the last one) is https://review.openstack.org/#/c/150066/
15:08:18 <ihrachyshka> all prev stuff is just to achieve this
15:08:28 <ihrachyshka> (which tells a lot about our tests)
15:09:12 <sc68cal> yeah the l3 agent is going through some big changes, for the better.
15:10:23 <baoli> ihrachyshka: will take a look sometime.
15:10:53 <ihrachyshka> thanks guys
15:11:09 <sc68cal> ihrachyshka: I saw your thread on the ML regarding sanity checks for dnsmasq version
15:11:24 <ihrachyshka> I was mainly interested in covering the module with tests to push for https://review.openstack.org/148017 (also worth checking on whether it's a correct path)
15:11:43 <ihrachyshka> sc68cal, yeah, I hope to kill that check asap since centos7+kilo is broken
15:11:49 <sc68cal> https://review.openstack.org/#/c/150066/
15:11:50 <ihrachyshka> but it's not strictly ipv6 :)
15:11:51 <sc68cal> doh
15:11:57 <sc68cal> http://lists.openstack.org/pipermail/openstack-dev/2015-January/053909.html
15:12:14 <ihrachyshka> for those interested, https://review.openstack.org/148577
15:13:41 <sc68cal> I get a little worried about them backporting stuff from 2.67 to 2.66 - but hey if that's what they want to do ...
15:13:52 <sc68cal> I wish them luck
15:14:07 <ihrachyshka> sc68cal, well, that's redhat
15:14:21 <ihrachyshka> we are profies in those kinds of perversions
15:14:27 <sc68cal> ihrachyshka: lol yep :)
15:15:50 <ihrachyshka> also of ipv6 note, juno freeze is approaching
15:15:58 <ihrachyshka> and I have some ipv6 backports: https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:stable/juno+topic:bug/1358709,n,z
15:16:48 <sc68cal> ihrachyshka: perfect I'll take a look
15:16:50 <ihrachyshka> one of those was discussed on prev meeting and we seemed to decide not to push for backport, but I thought since then and think that it's actually backportable, for the current behaviour is plain wrong.
15:16:55 <ihrachyshka> so, again, comments
15:16:56 <ihrachyshka> :)
15:18:18 <sc68cal> well, the original commit was filed as a bug... ;)
15:21:10 <sc68cal> dane_leblanc: how goes your patches>
15:21:20 <HenryG> I am in favour of those backports
15:21:40 <dane_leblanc> sc68cal: Fairly well, thanks. Got some reviews from baoli and Xu Han, thanks
15:22:08 <dane_leblanc> The first patch is failing some Tempest tests, I think I know the root causes, but fixing is tricky
15:23:24 <xuhanp> I was going to ask, how to fix tempest tests when the change in Neutron is not merged?
15:24:00 <xuhanp> it's kind of a chicken-egg problem
15:24:01 <dane_leblanc> xuhanp: The problems that I see so far are fixable within the patchset
15:24:13 <dane_leblanc> xuhanp: as far as I can tell.
15:24:16 <ihrachyshka> xuhanp, oh, have you heard about cross-repo deps patch for zuul?
15:24:31 <ihrachyshka> https://review.openstack.org/#/c/144555/
15:24:46 <xuhanp> ihrachyshka, good to hear that! Thanks
15:24:48 <ihrachyshka> it should bring us a Ponny Land
15:24:53 <sc68cal> excellent
15:24:55 <xuhanp> will take a look
15:25:18 <dane_leblanc> One of the problems that I see is that for SLAAC, we assume that the addresses are available upon subnet create (and we make associations for the ports on subnet create)
15:25:19 <sc68cal> that will be very useful
15:25:50 <dane_leblanc> But the addresses aren't really available until RADVD is spawned, and I think that happens when there's a router interface add
15:26:32 <xuhanp> dane_leblanc, I think this was discussed in your spec review. But I cannot remember the conclusion.
15:26:35 <dane_leblanc> So we may be making assumptions and displaying associations with SLAAC addresses which aren't available at the time.
15:27:05 <dane_leblanc> xuhanp: I don't think I nailed in 100% in the spec.
15:27:14 <aveiga> dane_leblanc: true, but those are available once RADVD is live.  It's not like they have to be populated in dnsmasq hosts or anything
15:27:36 <aveiga> since the addr is tied to the port's MAC
15:27:57 <ihrachyshka> dane_leblanc, what's the real problem? can we just avoid exposing those addresses if subnet is isolated?
15:28:09 <dane_leblanc> aveiga: Right, the addresses are actually available when radvd is live, but if we do a show ports before radvd is live, we'll show associations on the ports for the SLAAC addresses
15:29:04 <aveiga> I think we just need to roll with it though, since it isn't always radvd sending the RA
15:29:05 <dane_leblanc> Let's say someone creates a slaac subnet, but doesn't do add router interface to spawn radvd
15:29:45 <dane_leblanc> aveiga: I think we can distinguish the source of RA based on ra_mode
15:30:19 <dane_leblanc> So before add router interface is done, show ports will show associations with slaac addresses that aren't really there
15:30:19 <ihrachyshka> dane_leblanc, but ips are still available for usage, it's just that there is nothing that would automate it. same story for subnets with dhcp disabled.
15:30:42 <sc68cal> If I understand correctly, this is not really a new thing - since there is a time between when a port is assigned a IPv4 address and when the client actually does a DHCP request
15:30:52 <ihrachyshka> in theory, something inside instance may set addressing in an alternative way
15:31:01 <aveiga> also true
15:31:12 <aveiga> if you were using metadata, you can still use that assigned address
15:31:38 <dane_leblanc> ihrachyshka: for that scenario, ra_mode would be None, and ra_address_mode would be slaac
15:31:48 <aveiga> not necessarily
15:31:53 <dane_leblanc> Meaning, don't use openstack radvd
15:31:59 <aveiga> you might want the RAs there for routing purposes
15:32:09 <aveiga> but make your address stable
15:32:12 <ihrachyshka> how about 'don't use openstack radvd for now'?
15:32:45 <baoli> dane_leblanc: as long as the 'mode' says it's slaac, RA will run some where eventually, right?
15:32:59 <dane_leblanc> baoli: Eventually, yes
15:33:22 <dane_leblanc> I'm concerned with debuggability
15:33:58 <sc68cal> it should be easy to figure out - if a guest isn't getting a slaac address that means radvd is busted
15:34:00 <dane_leblanc> In the interval between when we're assuming slaac addresses are available and when they're actually available
15:34:17 <sc68cal> when modes are  slaac/slaac
15:35:19 <dane_leblanc> sc68cal: That's true, the guest would show whether the address is assigned or not, although openstack show ports might show something different
15:36:09 <ihrachyshka> I don't see how this requires special behaviour in comparison to dhcp disabled. show ports does not show active addresses of an instance but ip addresses available for usage using the port.
15:36:38 <aveiga> this is not divergent behavior
15:36:41 <baoli> dane_leblanc: may be a cli/api to show what radvd is currently doing would help
15:36:44 <aveiga> I think it's fine
15:36:58 <sc68cal> I think we can do a little hand-waving and say that Neutron always displays the desired behavior
15:37:38 <baoli> rather than digging it up manually.
15:37:53 <ihrachyshka> it's eventual consistency, dude. some day the instance will set the address.
15:38:35 <dane_leblanc> Okay, sounds like I'm outnumbered. :)  If the expectation is there that the show ports might not be 100% real, then it's okay.
15:38:57 <sc68cal> dane_leblanc: we're just trying to cut down on your workload :)
15:39:03 <ihrachyshka> lol
15:39:11 <dane_leblanc> sc68cal: So am I!
15:39:38 <dane_leblanc> sc68cal: This will determine a fix I need to make to get Tempest test working
15:39:50 <sc68cal> we should print a motto - "We'll fix it in P"
15:40:02 <dane_leblanc> sc68cal: Ha!
15:40:10 <aveiga> sc68cal: s/P/Current+1/g
15:40:40 <sc68cal> then we'll cross off P and write in new ones underneath
15:40:52 <dane_leblanc> Thanks for discussing this, good input.
15:45:17 <SridharG> Speaking of radvd reminds me to share my observations regarding radvd in an HA setup :-)
15:45:27 <SridharG> I've seen that in an HA Setup, radvd is spawned in all the HA Routers (irrespective of master/backup).
15:45:39 <SridharG> This was creating issues as the traffic from the standby/backup routers was causing the switch ports to reconfigure the IP/MAC port info as the
15:45:48 <SridharG> interfaces still had the LLA. Thanks to Assaf's patch [https://review.openstack.org/#/c/142843/] which is now merged and it addresses this issue .
15:46:24 <SridharG> I remember that we had a discussion earlier on the need for gratuitous arp for IPv6 subnets
15:46:25 <aveiga> SridharG: was it sending RAs without priority?
15:46:45 <aveiga> that's actually a valid config if the active was higher priority than the passive
15:46:51 <aveiga> because it would lower the failover time
15:47:18 <SridharG> aveiga: I've not checked the priority of RA
15:47:45 <SridharG> but AFAIK we do not change the priority of RADVD messages. So it would exactly be the same RA in all the HA router instances.
15:47:55 <aveiga> so that's the bug
15:47:56 <SridharG> what I actually wanted to convey is that...
15:48:10 <aveiga> running radvd on all instances is valid, but not if they'e the same priority
15:48:10 <SridharG> while discussing about GARP, some of you mentioned that it is not required as RA would serve the same purpose..
15:48:16 <SridharG> and this seems to be true.
15:49:10 <SridharG> aveiga: eventhough Radvd is running Assaf's patch would remove the LLA from the qr-xyz iface.
15:49:10 <sc68cal> aveiga: I think the problem was for HA routers they were using the same mac address
15:49:25 <SridharG> so the RA would not be seen by the instances/VMs.
15:49:26 <aveiga> oh, that's not good
15:49:42 <sc68cal> a follow up patch could add priority for ra packet and have different LLAs
15:50:09 <aveiga> yeah, I think we still need to figure out the multiple LLA thing
15:50:20 <aveiga> that was still up in the air if I remember correctly
15:51:16 <SridharG> yes sc68cal, the IP/MAC for the qg-xyz/qr-xyz would be the same on all the HA routers.
15:52:03 <aveiga> SridharG: I think the bigger question is which of the HA methods we want to support
15:52:16 <aveiga> you can do LLA spoofing similar to a VRRP mode
15:52:28 <aveiga> or multiple RAs from different LLAs with different priorities
15:52:43 <SridharG> aveiga: I'm talking about HA with Keepalived (VRRP)
15:53:04 <aveiga> is neutron managing keepalived?
15:53:09 <SridharG> yes
15:53:19 <aveiga> then I guess we'd better fix that setup :(
15:54:10 <SridharG> neutron spawns keepalived, but it uses scripts to get some notifications when there is a failover.
15:54:27 <SridharG> so I'm not sure, if its kind of straight forward.
15:56:21 <sc68cal> sounds like a summit session proposal ;)
15:56:57 <SridharG> lol
15:57:02 <aveiga> +1
15:57:09 <aveiga> or at least a pod session
15:58:16 <sc68cal> looks like we're nearly out of time
15:58:41 <Rajeev> AFAIK neutron is not notified of failover. Only the agents have that info
16:00:27 <SridharG> I agree with Rajeev, there seems to be some pending work to get the active HA router.
16:00:34 <sc68cal> Take care everyone, see you all next week
16:00:41 <sc68cal> #endmeeting