15:00:51 <sc68cal> #startmeeting neutron_ipv6
15:00:51 <openstack> Meeting started Tue Mar  3 15:00:51 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:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:55 <openstack> The meeting name has been set to 'neutron_ipv6'
15:01:42 <dane_leblanc> o/
15:01:51 <sc68cal> Since we're getting close to the K-3 deadline ( ttps://launchpad.net/neutron/+milestone/kilo-3 ) I'm going to leave the meeting pretty free-form and let people discuss patches and reviews
15:03:02 <sc68cal> HenryG: btw thanks for https://review.openstack.org/#/c/159994/
15:03:24 <sc68cal> (sharing for those who haven't seen it yet)
15:04:39 <HenryG> I had help from dane_leblanc dboik baoli to troubleshoot
15:05:16 <sc68cal> I know it's a big patch, but dane_leblanc 's review for the L3 agent fixes needs attention - I am guilty of not having a chance to review it yet. ( https://review.openstack.org/#/c/149068/ )
15:06:15 <dane_leblanc> sc68cal: Thanks, looking forward to getting some eyes on that to confirm this is the right direction.
15:06:43 <sc68cal> dane_leblanc: agreed - I just rebased my devstack-gate patch that sets IP_VERSION to 4+6 to depend on it
15:07:03 <sc68cal> so we'll see if a) zuul manages cross repo deps correctly and b) fixes the issue
15:07:20 <sc68cal> ( https://review.openstack.org/#/c/140128/ )
15:07:21 <dane_leblanc> sc68cal: Cool!
15:08:12 <baoli> for PD, Tomek has incorporated our proposed change (with rewritten by him) in the dibbler master, and he'd create an official dibbler release 1.0.1RC1
15:08:31 <dane_leblanc> There are also other multi-prefix patches, one which I owe a review change for baoli: #link https://review.openstack.org/#/c/113339/
15:09:41 <dane_leblanc> Also dboik's patch #link https://review.openstack.org/#/c/156360/
15:10:55 <baoli> The PD patch is here: https://review.openstack.org/#/c/158697/, and we're working on the unit test code to make it complete
15:11:30 <dane_leblanc> baoli: That's awesome news on the dibbler front.
15:11:36 <sc68cal> Indeed, congrats!
15:12:05 <baoli> dane_leblanc, yes indeed. It's really  nice of Tomek giving us full support on that.
15:12:28 <john-davidge> Yeah, Tomek has been great incorporating the changes so fast
15:12:41 <dane_leblanc> baoli: Congrats to you and john-davidge!
15:12:53 <baoli> and thanks for everyone who also helped on that
15:13:13 <dboik> baoli: john-davidge: yes, congrats!
15:13:31 <john-davidge> dboik: thanks :)
15:15:10 <HenryG> Great progress! But remember we need dibbler 1.01 included in the package libs used by the distros.
15:16:07 <sc68cal> Do we need to put a sanity check in, similar to what we do for dnsmasq version?
15:16:34 <john-davidge> sc68cal: Yes, definitely
15:16:43 <HenryG> sc68cal: A sanity check, yes. Checking the version number, though, is frowned upon.
15:16:59 <HenryG> We should check for the functionality we need.
15:17:36 <baoli> We can add the check to see if it supports the workdir switch, I suppose
15:17:49 <HenryG> Something like that, yes.
15:17:49 <sc68cal> that sounds good to me
15:18:23 <baoli> cool.
15:18:46 <sc68cal> BTW i'm seeing greens across the board in Zuul after setting the devstack-gate patch to depend on dane_leblanc 's
15:18:59 <sc68cal> super excited
15:19:14 <HenryG> nice!
15:19:32 <sc68cal> we'll have dual stack testing at the gate by kilo-3. This is fantastic
15:20:14 <baoli> sc68cal: a quick question about the dual stack. Does that mean the gate will always run as dual stack?
15:20:40 <sc68cal> my patch sets IP_VERSION="4+6" when neutron is enabled in devstack
15:20:43 <sc68cal> so yes
15:21:13 <sc68cal> it's not the default in devstack, it's just when devstack is run by devstack-gate
15:21:25 <baoli> sc68cal, ok, thanks.
15:21:43 <HenryG> Step 1: make neutron the default in devstack
15:21:59 <sc68cal> which I have worked on :)
15:22:01 <HenryG> Step 2: make 4+6 the default in devstack
15:22:10 <HenryG> Step 3: ????
15:22:19 <dane_leblanc> Maybe a dumb question, but could the gate tests be changed to ping an external router? AFAIK the tempest tests only ping as far as the neutron gateway port?
15:22:23 <HenryG> step 4: ... profit!
15:22:39 <haleyb> world domination ?
15:22:43 <sc68cal> dane_leblanc: that's a good suggestion, I know at least one cloud has v6 enabled, so we can do just that
15:22:55 <sc68cal> and routers advertising routes, so we can test end to end
15:23:38 <baoli> sc68cal, so this is the devstack gate, does other gate jobs (for example neutron) depends on it? I'm not familiar with the gate jobs. That's why my question.
15:24:37 <sc68cal> baoli: yes, devstack-gate is a piece of code that configures devstack for all the jobs that the gate runs. So in this case, whenever Neuron is set up by devstack - for example, neutron's runs, tempest, etcc.. this will have IP_VERSION="4+6+
15:25:50 <absubram> sc68cal: An update on another v6 BP ipv6-router.. It is out for review - https://review.openstack.org/#/c/156283/ .. thank xuhanp for the initial review last week!
15:26:19 <absubram> It is no longer WIP but I have -1’d it for now.. I have just a couple more minor tweaks to put in place and some final testing to be completed.. including a 4+6 dual stack test and a final ping test..
15:26:36 <baoli> sc68cal: thanks. If that's the case, I wonder should the gate also run as v4, v6, v4+v6 separately at some point.
15:27:19 <sc68cal> baoli: probably v4+v6 and v6 only at some point. Not sure about v4 only since your settings in devstack are additive, they don't change v4 if I'm not mistaken
15:27:27 <dane_leblanc> HenryG: Do the gating tests use the cirros image that does SSH v6 but not ping6? (I think that's what came up yesterday)
15:28:51 <HenryG> dane_leblanc: I started looking into it and didn't really confirm, but it seems no SSH v6 support in the gate's cirros.
15:28:55 <sc68cal> yeah HenryG and I were just talking about that in openstack-neutron - we need to track https://bugs.launchpad.net/cirros/+bug/1366326
15:28:56 <openstack> Launchpad bug 1366326 in CirrOS "ipv6 support" [Medium,Confirmed]
15:29:07 <haleyb> i know there is no ping6 in the cirros image
15:30:47 <dane_leblanc> Whoever "Unassigned" is, they have their work cut out for them for that Cirros bug.
15:30:57 <sc68cal> :)
15:31:04 <dboik> lol
15:31:19 <baoli> sc68cal, you can set it as 4, 6, or 4+6. I guess that tempest tests were not depending on the IP_VERSION setting.
15:32:31 <sc68cal> baoli: correct
15:32:37 <sc68cal> not directly
15:32:53 <sc68cal> but the devstack build that is run, in order to do the tempest tests depended.
15:33:53 <baoli> HenryG: a question, so the v6 test you fixed depends on v4 connectivity?
15:33:58 <SridharG> In tempest, the tests would be run if CONF.network_feature_enabled.ipv6 is set.
15:34:05 <HenryG> baoli: it does
15:34:52 <baoli> HenryG, if at some point, we'd test v6-only setup, the test would have to be rewritten (or revised)
15:35:23 <HenryG> baoli: Yes, currently that test also sets up v4 addresses, so for now that's how it works.
15:35:49 <sc68cal> Yes, this is tracked by this bug https://bugs.launchpad.net/tempest/+bug/1401726
15:35:51 <openstack> Launchpad bug 1401726 in tempest "Tempest IPv6 scenario tests use IPv4 and floating IPs to connect and test" [High,Confirmed] - Assigned to Sean M. Collins (scollins)
15:35:59 <baoli> SridharG, in that case, it may make sense to set CONF.network_feature_neabled.ipv6 based on the devstack setting.
15:37:08 <SridharG> baoli: yes, I agree.
15:37:47 <sc68cal> it might be the reverse
15:37:57 <sc68cal> have devstack set the tempest variable
15:38:21 <sc68cal> if IP_VERSION has 6 in it, do an iniset in tempest's conf
15:40:23 <SridharG> yes sc68cal. We probably need a patch in devstack to set the tempest conf (CONF.network_feature_enabled.ipv6) if IP_VERSION has 6 in it.
15:41:15 <baoli> sc68cal, ScridharG, and the devtest setting should be based on the Testbed that the gate jobs are runnning on, I suppose
15:42:29 <sc68cal> possibly. I'll probably run a re-check or two, see if I can get scheduled on the non-ipv6 cloud (I forget which is the one that isn't, HP or RAX) and see if it fails
15:42:46 <sc68cal> when there is no external ipv6
15:43:11 <haleyb> the non-ipv6 cloud would be hp :(
15:43:44 <HenryG> But you are fixing that, right haleyb? :)
15:44:12 <haleyb> It's a long story....
15:44:26 <dane_leblanc> haleyb: Non-ipv6 means there is no external IPv6 router... or there is no IPv6 on the host platform?
15:44:59 <haleyb> there is no external router
15:45:37 <SridharG> If we are only going to test neutron API for IPv6 features (i.e., IPv6 subnet creation, ssh connectivity) for "tenant" networks, I guess we can run on any Testbed right? We need support from platform/test-bed only if we are looking at an external IPv6 connectivity use-case isnt it?
15:45:49 <sc68cal> SridharG: correct
15:46:22 <haleyb> right, i can create a devstack testbed inside any cloud that supports ipv6, it just can't always get to the v6 internet
15:46:46 <baoli> SridharG, correct.
15:47:13 <SridharG> True. So probably we need a new flag in tempest for external_ipv6 use-cases. The current flag can validate all the tenant IPv6 features.
15:50:55 <SridharG> by doing this we can validate the IPv6 tenant use-cases in the gate (by default).
15:51:03 <dane_leblanc> The tests can still go as far as pinging the router gateway interface, just won't be able to do end-to-end pings to external V6 on the non-V6 platform.
15:52:24 <SridharG> dane_leblanc: +1
15:52:58 <baoli> with more v6 related code added, the system behave differently with 4, 6, 4+6 even just on the api level. So it may make sense to run the gate jobs separately.
15:57:11 <haleyb> So i'll just plug my latest review for fixing address family usage in ip_lib, https://review.openstack.org/#/c/157555/
15:57:43 <haleyb> not sure if some of those changes are needed by the cisco team's code
15:57:47 <sc68cal> cool, I'll check out the latest
15:58:34 <HenryG> haleyb: It's a good change, but touches a lot of methods. Needs plenty of reviewers.
15:58:41 <dane_leblanc> haleyb: Looks similar to what I was doing in my patch for multi-prefix
15:58:49 <baoli> haleyb: will take a look
16:00:13 <haleyb> yes, part of it was stolen from Sridhar's patchset, and it does touch more than i planned
16:01:30 <SridharG> haleyb: no issues at all :-) I had a look at your patchset, it looks good.
16:02:10 <dane_leblanc> haleyb: Looks good, will have to undo some stuff in my patch, but this was definitely needed.
16:02:25 <sc68cal> ok all, we're out of time
16:02:39 <sc68cal> #endmeeting