15:00:51 #startmeeting neutron_ipv6 15:00:51 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:55 The meeting name has been set to 'neutron_ipv6' 15:01:42 o/ 15:01:51 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 HenryG: btw thanks for https://review.openstack.org/#/c/159994/ 15:03:24 (sharing for those who haven't seen it yet) 15:04:39 I had help from dane_leblanc dboik baoli to troubleshoot 15:05:16 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 sc68cal: Thanks, looking forward to getting some eyes on that to confirm this is the right direction. 15:06:43 dane_leblanc: agreed - I just rebased my devstack-gate patch that sets IP_VERSION to 4+6 to depend on it 15:07:03 so we'll see if a) zuul manages cross repo deps correctly and b) fixes the issue 15:07:20 ( https://review.openstack.org/#/c/140128/ ) 15:07:21 sc68cal: Cool! 15:08:12 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 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 Also dboik's patch #link https://review.openstack.org/#/c/156360/ 15:10:55 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 baoli: That's awesome news on the dibbler front. 15:11:36 Indeed, congrats! 15:12:05 dane_leblanc, yes indeed. It's really nice of Tomek giving us full support on that. 15:12:28 Yeah, Tomek has been great incorporating the changes so fast 15:12:41 baoli: Congrats to you and john-davidge! 15:12:53 and thanks for everyone who also helped on that 15:13:13 baoli: john-davidge: yes, congrats! 15:13:31 dboik: thanks :) 15:15:10 Great progress! But remember we need dibbler 1.01 included in the package libs used by the distros. 15:16:07 Do we need to put a sanity check in, similar to what we do for dnsmasq version? 15:16:34 sc68cal: Yes, definitely 15:16:43 sc68cal: A sanity check, yes. Checking the version number, though, is frowned upon. 15:16:59 We should check for the functionality we need. 15:17:36 We can add the check to see if it supports the workdir switch, I suppose 15:17:49 Something like that, yes. 15:17:49 that sounds good to me 15:18:23 cool. 15:18:46 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 super excited 15:19:14 nice! 15:19:32 we'll have dual stack testing at the gate by kilo-3. This is fantastic 15:20:14 sc68cal: a quick question about the dual stack. Does that mean the gate will always run as dual stack? 15:20:40 my patch sets IP_VERSION="4+6" when neutron is enabled in devstack 15:20:43 so yes 15:21:13 it's not the default in devstack, it's just when devstack is run by devstack-gate 15:21:25 sc68cal, ok, thanks. 15:21:43 Step 1: make neutron the default in devstack 15:21:59 which I have worked on :) 15:22:01 Step 2: make 4+6 the default in devstack 15:22:10 Step 3: ???? 15:22:19 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 step 4: ... profit! 15:22:39 world domination ? 15:22:43 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 and routers advertising routes, so we can test end to end 15:23:38 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 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 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 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 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 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 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 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 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 Launchpad bug 1366326 in CirrOS "ipv6 support" [Medium,Confirmed] 15:29:07 i know there is no ping6 in the cirros image 15:30:47 Whoever "Unassigned" is, they have their work cut out for them for that Cirros bug. 15:30:57 :) 15:31:04 lol 15:31:19 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 baoli: correct 15:32:37 not directly 15:32:53 but the devstack build that is run, in order to do the tempest tests depended. 15:33:53 HenryG: a question, so the v6 test you fixed depends on v4 connectivity? 15:33:58 In tempest, the tests would be run if CONF.network_feature_enabled.ipv6 is set. 15:34:05 baoli: it does 15:34:52 HenryG, if at some point, we'd test v6-only setup, the test would have to be rewritten (or revised) 15:35:23 baoli: Yes, currently that test also sets up v4 addresses, so for now that's how it works. 15:35:49 Yes, this is tracked by this bug https://bugs.launchpad.net/tempest/+bug/1401726 15:35:51 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 SridharG, in that case, it may make sense to set CONF.network_feature_neabled.ipv6 based on the devstack setting. 15:37:08 baoli: yes, I agree. 15:37:47 it might be the reverse 15:37:57 have devstack set the tempest variable 15:38:21 if IP_VERSION has 6 in it, do an iniset in tempest's conf 15:40:23 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 sc68cal, ScridharG, and the devtest setting should be based on the Testbed that the gate jobs are runnning on, I suppose 15:42:29 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 when there is no external ipv6 15:43:11 the non-ipv6 cloud would be hp :( 15:43:44 But you are fixing that, right haleyb? :) 15:44:12 It's a long story.... 15:44:26 haleyb: Non-ipv6 means there is no external IPv6 router... or there is no IPv6 on the host platform? 15:44:59 there is no external router 15:45:37 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 SridharG: correct 15:46:22 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 SridharG, correct. 15:47:13 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 by doing this we can validate the IPv6 tenant use-cases in the gate (by default). 15:51:03 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 dane_leblanc: +1 15:52:58 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 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 not sure if some of those changes are needed by the cisco team's code 15:57:47 cool, I'll check out the latest 15:58:34 haleyb: It's a good change, but touches a lot of methods. Needs plenty of reviewers. 15:58:41 haleyb: Looks similar to what I was doing in my patch for multi-prefix 15:58:49 haleyb: will take a look 16:00:13 yes, part of it was stolen from Sridhar's patchset, and it does touch more than i planned 16:01:30 haleyb: no issues at all :-) I had a look at your patchset, it looks good. 16:02:10 haleyb: Looks good, will have to undo some stuff in my patch, but this was definitely needed. 16:02:25 ok all, we're out of time 16:02:39 #endmeeting