14:00:20 <armax> #startmeeting networking 14:00:20 <openstack> Meeting started Tue Feb 10 14:00:20 2015 UTC and is due to finish in 60 minutes. The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:23 <openstack> The meeting name has been set to 'networking' 14:00:30 <armax> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda 14:00:34 <emagana> anteaya: I just woke up.. maybe not very productive 14:00:49 <marun> armax: pong 14:00:50 <anteaya> emagana: you're singing my song 14:00:57 <armax> as usual…a reminder of the important dates 14:01:08 <armax> (which are fast approaching) 14:01:09 <armax> Feature Proposal Freeze: March 5 14:01:16 <armax> Feature, String, and Dependency Freeze: March 19 14:01:22 <armax> RCs: April 9-23 14:01:29 <armax> Kilo release: April 30 14:02:01 <salv-orlando> aloha? 14:02:11 <armax> salv-orlando: aloha! 14:02:55 <armax> please make sure that if you have a feature that needs to hit the Kilo deadline, the code is posted by the feature proposal freeze deadline 14:03:20 <armax> the current K3 backlog is https://launchpad.net/neutron/+milestone/kilo-3 14:03:40 <armax> #announcement: by the way K2 is out: https://launchpad.net/neutron/+milestone/kilo-2 14:03:58 <armax> #undo 14:03:59 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x995ea50> 14:04:15 <armax> #topic Announcements by the way K2 is out: https://launchpad.net/neutron/+milestone/kilo-2 14:04:53 <salv-orlando> that's a nice topic 14:04:58 <ajo> :-) 14:05:14 <armax> salv-orlando: that’s custom made, just for you! 14:05:20 <armax> ok, let’s move on... 14:05:25 <armax> #topic Bugs 14:05:32 <armax> enikanorov: you’re up 14:05:42 <salv-orlando> anyway, if you want this in minutes you can use the info hashtag 14:06:32 <armax> enikanorov_: ping 14:06:33 <enikanorov_> armax: not much to update this week 14:07:14 <salv-orlando> enikanorov: do you have a status about how gate jobs are doing? 14:07:53 <ajo> I need to look back at this bug: 14:07:56 <ajo> https://bugs.launchpad.net/neutron/+bug/1410982 14:07:56 <openstack> Launchpad bug 1410982 in neutron "test_slaac_from_os frequent failures" [High,Confirmed] - Assigned to Miguel Angel Ajo (mangelajo) 14:07:56 <enikanorov_> salv-orlando: based on my observations, there were no major neutron-related failures 14:08:11 <armax> ajo: great 14:08:15 <ajo> At some point in time, one of my patches raised the failure rate a lot, 14:08:19 <armax> ajo: is there anything we can help you with? 14:08:29 <ajo> but, then it went back to it's usual state (it had been there for a long time) 14:08:34 <salv-orlando> enikanorov_: without gate unreliability, neutron is not fun anymore. 14:08:45 <ajo> armax, I will re-evaluate the situation to see how it's now 14:08:50 <marun> salv-orlando: you have a funny definition of 'fun' :P 14:08:53 <ajo> armax and I will keep you updated 14:08:56 <armax> ajo: ok ping me if you need help 14:09:00 <ajo> ack 14:09:15 <enikanorov_> salv-orlando: ha. so we;ve been having all those issues because you wanted to have fun? ;) 14:09:27 <armax> ok, we cannot make fun of Neutron instability anymore, by the sounds of it 14:09:38 <marun> armax: let's not be hasty... 14:09:45 <armax> marun: :) 14:10:22 <armax> ok, does anyone have any other issue they would like to discuss/raise awareness here? 14:10:25 <salv-orlando> enikanorov_: you're making it sound as if I introduced those bugs on purpose 14:10:53 <armax> if not we can switch to… 14:10:55 <salv-orlando> one thing from me... 14:11:02 <armax> … 14:11:06 <armax> salv-orlando: shoot 14:11:14 <enikanorov_> salv-orlando: ;) 14:11:17 <salv-orlando> there has been a lot of discussion recently on MTU selection and impact on GRE communication 14:11:29 <salv-orlando> do we want to spend some times on it now or open discussion? 14:11:45 <armax> we can leave it to the open discussion, IMO 14:11:53 <ajo> +1 14:11:56 <salv-orlando> I just want to have a picture of the current status (I think I have it) and whether we'll manage to fix it for good for kilo 14:12:08 <salv-orlando> open discussion it is thn 14:12:14 <armax> salv-orlando: ok 14:12:20 <armax> #topic Docs 14:12:22 <ajo> salv-orlando, it's an interesting topic to me :) 14:12:25 <armax> emagana: you awake? 14:12:30 <ajo> :) 14:12:33 <emagana> armax: barely! 14:12:45 <armax> emagana: shall we come back in a few hours? :) 14:12:45 <ajo> thank you for all the USA people from joining at this early time ;) 14:13:03 <ajo> from joining? for joining... 14:13:20 <emagana> Ok! The Networking Docs team is moving the initial scenarios legacy for both LB and OVS out of github 14:13:32 <emagana> They will be in gerrit anytime soon for your review! 14:13:36 <armax> emagana: good stuff 14:14:01 <emagana> We believe they are in good shape to start the normal gerrit process 14:14:33 <armax> emagana: is there anyone we’d need to earmark for review? 14:14:52 <markmcclain> emagana: awesome 14:14:55 <emagana> I was asked if someone could help on this bug: https://review.openstack.org/#/c/122024/ 14:15:17 <emagana> armax: everybody! but the gerrit commit is not there yet! 14:15:35 <emagana> It should happen this week, I will send a note to the mailing list 14:15:50 <armax> emagana: not sure I see the relationship between docs and #link https://review.openstack.org/#/c/122024/ 14:16:16 <armax> emagana: ok, great…when the link is out, please feel free to tag me as reviewer 14:16:19 <armax> thanks 14:16:22 <emagana> armax: One of the scenarios is blocked because of this bug: https://bugs.launchpad.net/neutron/+bug/1369721 14:16:22 <openstack> Launchpad bug 1369721 in neutron "manually moving dvr-snat router fails" [High,In progress] - Assigned to Mike Smith (michael-smith6) 14:16:32 <armax> emagana: understood 14:16:50 <armax> I think Mike is OOO 14:16:51 <marun> emagana: btw, once this lands, doc changes won't be subject to tempest/rally/grenade jobs :) https://review.openstack.org/#/c/152298/ 14:17:23 <armax> marun: that is some great news! 14:17:36 <emagana> marun: Thanks for sharin! 14:17:41 <armax> we should probably make a big announcement when that happens 14:18:11 <armax> emagana: anything else? 14:18:23 <emagana> sadly I haven't done personally much progress on the migration from nova-net scenario :-( 14:18:49 <emagana> I know anteaya and obondarev and looking forward to reviewwing that part.. my apologies 14:19:00 <armax> I guess that brings us to the next topic 14:19:03 <emagana> reviewing* 14:19:08 <anteaya> emagana: we can talk about that after the meeting 14:19:12 <armax> #topic Open Discussion 14:19:15 <emagana> anteaya: sure! 14:19:23 <armax> we have a few items on the agenda 14:19:35 <ajo> salv-orlando: GRE/mtu ? 14:19:42 <armax> one of it is Nova-network to Neutron migration 14:19:46 <anteaya> hello 14:19:48 <armax> anteaya: ping 14:20:04 <armax> ajo: in due course ;) 14:20:05 <anteaya> we are making progress 14:20:09 <salv-orlando> basically it's been a lot of releases now that we're leaving to the deployer the onus of setting it up 14:20:15 <anteaya> armax: thanks for merging the first part of the spec 14:20:18 <salv-orlando> ajo: ^^ 14:20:28 <armax> anteaya: np 14:20:44 <anteaya> now we need to get that documented with emagana's help so that sdague has something to show operators at their meetup in the second week of march 14:21:00 <armax> anteaya: I believe that the second half is still up for review 14:21:15 <emagana> anteaya: I will be at the operators meetup as well! 14:21:18 <anteaya> and we have jlibosva's patch which he is going to work with a operator to get to the testing stage 14:21:26 <anteaya> armax: yes it is 14:21:31 <anteaya> emagana: awesome 14:21:39 <markmcclain> is there any reason to keep blocking teh 2nd half of the review? 14:21:53 <markmcclain> seems like we should be able to merge and then update as we progress 14:21:53 <emagana> marun: I have the same question!! 14:21:58 <anteaya> so the second part of the spec needs working code for some reviews to feel comfortable with the second part of the spec 14:22:20 <markmcclain> anteaya: I can see that, but it's not like we're carving stone 14:22:23 <emagana> are we all talking about this one: https://review.openstack.org/#/c/142456? 14:22:24 <anteaya> markmcclain: dansmith said at nova meetup he wanted to see code 14:22:35 <armax> emagana: yes 14:22:43 <anteaya> markmcclain: well I don't feel we are blocking the spec, it is being worked on 14:22:49 <anteaya> markmcclain: do you feel it is blocked? 14:23:19 <markmcclain> anteaya: if as long as you don't feel like that is a blocker then I'm fine with the current direciton 14:23:26 <anteaya> to continue there is some question on the proxy patch to clarify is is required 14:23:27 <armax> markmcclain: it sounds to me that we can approve it or not…what counts is the code underpinning it 14:23:37 <markmcclain> armax: exactly 14:23:58 <anteaya> #link https://review.openstack.org/#/q/topic:bp/migration-from-nova-net,n,z 14:24:16 <anteaya> well dansmith was fairly specific 14:24:27 <anteaya> and since we could get to a place where he could agree 14:24:28 <armax> markmcclain: so what action plan do you propose? 14:24:28 <salv-orlando> it's not like we're required to sign it with out blood in order to approve it. I guess we can say that it's kind of ok for now 14:24:35 <salv-orlando> *our blood 14:24:40 <anteaya> I don't want him to feel his request is being dismissed 14:24:50 <anteaya> as I told him I thought his request was reasonable 14:25:13 <markmcclain> armax: if anteaya is happy then let's keep the direction 14:25:17 <anteaya> what would happen with the spec approved now as opposed to our current workflow? 14:25:24 <anteaya> is there a piece I am missing? 14:25:32 <armax> I am happy if anteaya is happy 14:25:43 <anteaya> we are making good progress by my measurement and not upsetting folks thus far 14:25:46 <markmcclain> anteaya: no.. I was just making sure that the unapproved spec wasn't something hindering progress 14:25:46 <anteaya> thanks 14:25:59 <anteaya> ah okay, I don't feel it is 14:26:08 <anteaya> I expect some pushback after the ops meeting 14:26:20 <anteaya> as I am guessing many haven't been paying attention 14:26:21 <ajo_> sorry, OSX blew up... ;/ 14:26:27 <armax> ok, let’s keep reviewing the spec and make progress on the code, and we’ll reassess the situation in a week’s time 14:26:34 <anteaya> thanks 14:26:36 <anteaya> done 14:26:45 <armax> let’s move on the next topic on the open discussion 14:26:54 <armax> quick update on Plugin Decomp 14:27:33 <armax> a few folks are going through the motions 14:28:38 <armax> I would like to remind you that, in order to get reviewer attention, it’s useful to have the review commit message mention the blueprint topic 14:28:59 <ihrachyshka> on that note, I also want to note that we should make sure that old full python paths work for decomposed plugins 14:29:02 <armax> the latest status is reported here #link https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition 14:29:20 <ihrachyshka> f.e. see https://review.openstack.org/151893 that moves files to different places. 14:29:21 <armax> if you don’t see your plugin/driver here: https://docs.google.com/spreadsheets/d/1OQN0VlKzKC1gYlxgalQXKDTGGWogWFRtD3S5OpepsX4 14:29:27 <armax> ping me directly in channel 14:29:45 <armax> ihrachyshka: thanks I’ll look into it 14:29:58 <marun> /url 1 14:30:11 <armax> another ongoing effort is to document the ‘contribution’ steps for new or existing folks 14:30:17 <armax> this is taking shape here: #link https://github.com/openstack/neutron/blob/master/doc/source/devref/contribute.rst 14:31:00 <armax> ok 14:31:14 <armax> on the next open discussion item... 14:31:15 <armax> Multiple template libraries being used in-tree 14:31:21 <armax> who did put this on the agenda? 14:31:37 <markmcclain> didn't this come from the ML discussion from sc68cal? 14:31:49 <armax> sc68cal: you there? 14:32:11 <markmcclain> he had noticed that we were using both mako and jinja2 14:32:38 <markmcclain> but mako was a drive by from alembic… I think we had only been explicitly using jinja2 14:32:45 <armax> ok, it looks like sc68cal is not around.. 14:32:51 <armax> markmcclain: what do you suggest? 14:32:54 <markmcclain> that's status quo…we should keep 14:33:01 <ihrachyshka> +1 14:34:06 <marun> the review that triggered his concern won't need a templating language at all, so the issue should be moot 14:34:09 <marun> https://review.openstack.org/#/c/128259/ 14:34:52 <armax> so is the resolution to drop mako? 14:35:01 <marun> jschwarz was intending to use templates to drive configuration in testing. I've convinced him to generate the files without templates instead 14:35:16 <marun> alembic will still require mako 14:35:28 <marun> but we won't be adding an explicit dependency of our own - we'll continue to use jinja2 14:35:48 <ajo_> +1 14:35:49 <armax> marun: that’s my understanding 14:36:03 <ajo_> that's my understanding too 14:36:20 <salv-orlando> I don't think anybody is troubled by this 14:36:42 <HenryG> I agree, it's a non-issue 14:36:55 <armax> yup 14:36:59 <ajo> correct 14:37:09 <armax> it sounds like we should just say on https://review.openstack.org/#/c/128259 that Mako should not be in the requirements? 14:37:31 <marun> armax: I've already -1'd on the issue of using templates at all 14:37:38 <armax> marun: cool 14:37:56 <armax> one last reported item on the open discussion agenda is ‘Neutron as the default in Devstack' 14:38:14 <marun> otherwiseguy: around? :) 14:38:17 <armax> it looks like that we did switch for a bit, only to back out because of a config problem 14:38:44 <salv-orlando> the change was reverted because it seems like people need to add a few config params explicitly to localrc 14:38:47 <armax> anyone has suggestions on how to get to resolution? 14:38:53 <marun> otherwiseguy found a solution to the 'vms can see the world' problem that folks were reporting 14:39:09 <salv-orlando> the desire apparently is to make it work out of the box, and therefore to me this means providing reasonable defaults for every parameter 14:39:12 <armax> otherwiseguy: do I hear that you’re voluteering? 14:39:14 <marun> I think that's the biggest problem preventing from 'just working' 14:39:21 <armax> :) 14:39:34 <ajo> ah, so people used to nova expected VMs to go "to the world" 14:39:35 <marun> armax: he's pretty busy with the ovsdb work, so if anyone else can pick it up that would be helpful 14:39:42 <ajo> instead of just to the local virtual network with the devstack vm? 14:39:50 <marun> ajo: Apparently so 14:39:55 <ajo> ah, ok 14:39:56 <armax> marun: let’s hear it from otherwiseguy :P 14:40:19 <marun> armax: basically though, the solution is to double nat 14:40:19 <markmcclain> we should be able to bridge the router's ext net to the the upstream interface like nova-net does right? 14:40:23 <ajo> I guess we need to plug the main interface to br-ex 14:40:39 <markmcclain> marun: why double nat? 14:41:06 <marun> markmcclain: you'd have to ask otherwiseguy. If you can think of an easier way, great. 14:41:32 <armax> it sounds like a solution is within reach, we’d need to find someone championing this change 14:41:50 <marun> armax: wait... 14:41:54 <marun> there was an etherpad... 14:42:28 <marun> https://etherpad.openstack.org/p/devstack-neutron-default 14:42:35 <marun> it wasn't just 14:42:39 <marun> vm's can see the world 14:43:03 <marun> sdague and co put together this etherpad of requirements that they wanted to see met for having neutron become the default 14:43:13 <marun> based on their experience of trying it out briefly last week 14:43:25 <armax> marun: great 14:43:31 <armax> #link https://etherpad.openstack.org/p/devstack-neutron-default 14:43:34 <markmcclain> ok.. those are all reasonable 14:43:48 <markmcclain> do we have a bug for this in neutron or devstack? 14:44:00 <marun> markmcclain: I'm not sure, mestery would know 14:44:08 <marun> or sdague 14:44:09 <markmcclain> ok.. I'll follow up with him 14:44:15 <markmcclain> or both 14:44:30 <otherwiseguy> marun: just woke up 14:44:33 <armax> #action markmcclain to follow up with mestery in relation to Neutron as default in Devstack 14:45:13 <armax> I don’t believe there’s a bug no 14:45:14 <marun> otherwiseguy: maybe you can talk with markmcclain about why double nat is a good way to allow VM's to see the world? 14:45:27 <marun> otherwiseguy: he seemed to have questions 14:45:51 <markmcclain> we can work on this outside the meeting… since there's only 3 of us talking 14:46:00 <otherwiseguy> ok 14:46:05 <ajo> i'm reading 14:46:06 <ajo> :D 14:46:07 <armax> ok, let’s move on 14:46:13 <armax> salv-orlando, ajo: MTU 14:46:25 <markmcclain> ajo: we'll chat in -neutron so you can keep following :) 14:46:26 <ajo> true 14:46:30 <salv-orlando> I don't want to bother people to much 14:46:43 <ajo> markmcclain: ack 14:46:53 <ajo> salv-orlando: what's the issue with GRE and mtu selection? 14:47:11 <ajo> salv-orlando: does it break some thing?, I'm still missing some context, I guess 14:47:18 <salv-orlando> At this stage my only question is about 1) the status of mut-selection-and-adverstiment 2) whether people that know about its progress whether they can say if it's going to solve issues observed by sers 14:48:01 <salv-orlando> ajo: I am referring to recent posts on the mailing list, where users have reported fragmentation occurring at different layers, and bandwidth on gre networks dropping to 23kb/s with 10GB links 14:48:14 <ajo> salv-orlando: 1) I saw initial model implementation, if that was the question: https://review.openstack.org/153733 14:48:50 <armax> salv-orlando: the model change merged here https://review.openstack.org/#/c/153451/ 14:48:53 <ajo> salv-orlando, I've myself experienced that, due to inability to control MTU internally (neutron) or externally (the IP network I was using) 14:49:26 <ajo> ah, the other link were just settings, right, thanks armax 14:49:41 <ajo> salv-orlando, what's the topic on the mail list? 14:50:16 <salv-orlando> cool, so basically the approach we'll go for is that it will be up to the user to choose the right one. It might be reasonable, not 100% if that's what users are expecting, but I'm not the one who can judge it 14:50:18 <ajo> ahh, "higher MTU for all interfaces" ? 14:50:39 <ajo> yes, sometimes you don't have control over your L2 infrastructure to allow higher mtu, 14:50:46 <ajo> or... it's not capable over all the L3 hops 14:50:48 <salv-orlando> ajo: http://lists.openstack.org/pipermail/openstack/2015-January/011207.html 14:50:49 <armax> salv-orlando: frankly I don’t believe that at this point can really do anything smarter than that 14:51:12 <ajo> so, in that case is only possible to internally use a lower mt 14:51:14 <ajo> mt->mtu 14:51:16 <salv-orlando> armax: that's good for me. I thought people smarter than me might have smarter ideas 14:51:28 <armax> but I would be eager to see the rest of the impleemtnation from ijw’s spec 14:51:35 <armax> *implementation 14:51:53 <HenryG> I can ask the folks working on the implementation to give a progress report 14:51:55 <ajo> salv-orlando, thanks for the link, I was looking at a different thread 14:52:05 <ihrachyshka> hm. in that spec, weren't we going to encode max-mtu for tunnels in physnet definition? I think that's smart enough to solve perf drop, isn't it? 14:52:10 <armax> HenryG: that would be super-duper 14:52:34 <ajo> salv-orlando, I actually helped eren debug that problem on the neutron channel 14:52:41 <ajo> but, I couldn't replicate it in my environment, 14:52:48 <ajo> it seems related to his kernel version or something.. 14:53:08 <ajo> my LB's didn't defragment packets.. 14:53:08 <armax> ok, time check... 14:53:16 <armax> 8 minutes to the end of the meeting 14:53:29 <armax> #action HenryG to follow up to see the progress of the MTU spec 14:53:43 <armax> and then we can take the disucssion on the review(s) 14:53:46 <armax> anything else? 14:53:50 <ajo> Thanks HenryG 14:53:51 <armax> on this topic? 14:54:05 <armax> looks like we’re good 14:54:13 <anteaya> I would like to mention since we are in open discussion, that alaski is looking for a neutron point person to co-ordinate communication with nova cells, as currently neutron doesn't know about it 14:54:13 <armax> I’d like to bring a topic to attention 14:54:29 <armax> anteaya: excellent point 14:54:44 <ajo> yes, good point 14:54:44 <armax> anyone willing to help? Don’t rush all at once 14:54:47 <anteaya> thanks, so the hunt for a volunteer is ongoing 14:55:02 <armax> anteaya: where is alaski based? I mean what timezone? 14:55:14 <anteaya> armax: not exactly sure, I'm guessing pst 14:55:29 <alaski> I'm EST 14:55:40 <anteaya> alaski: the man himself, thank you 14:55:44 <armax> alaski: ok great, welcome 14:56:02 <alaski> thanks 14:56:04 <armax> alaski: let’s talk briefly in the neutron channel 14:56:12 <armax> I’ll ping you after the meeting 14:56:18 <armax> dougwig: ping 14:56:23 <alaski> armax: sounds good 14:57:14 <armax> it sounds like all the adv-svc projects depend on a copy of netron that comes out of git 14:57:18 <armax> like: https://github.com/openstack/neutron-fwaas/blob/master/requirements.txt#L18 14:57:33 <armax> not only these projects like fw, vpn and lb 14:57:39 <markmcclain> right this is know problem 14:57:49 <armax> but also stackforge projects that are taking shape 14:57:52 <armax> markmcclain: correct, 14:57:54 <ihrachyshka> do you want to publish releases on pypi? 14:57:57 <armax> I wonder if we have a resolution 14:58:18 <armax> ihrachyshka: we could, only if we can tag arbitrarely 14:58:19 <markmcclain> ihrachyshka: none of hte other server projects are pushed to pypi 14:58:28 <armax> markmcclain: ya 14:58:32 <ihrachyshka> that would also slow down changes since we would have delay between time when neutron is patched and the code reaches aas repos 14:58:34 <armax> that’s what I noticed 14:58:37 <markmcclain> armax: we can tag, but releasing creates a lot of problems 14:58:52 <marun> it solves some, too 14:59:02 <armax> markmcclain: if we could tag, that would be a good enough stop-gap 14:59:10 <ihrachyshka> can we depend on tag in reqs.txt? 14:59:11 <armax> but I would like to understand what is the crux of the matter 14:59:17 <otherwiseguy> also I think neutron gate tempest tests can fail if *aas breaks. 14:59:27 <markmcclain> armax, ihrachyshka: testing in the gate will be a mess 14:59:32 <marun> otherwiseguy: we'll need to fix that for sure 14:59:34 <armax> but perhaps we can discuss this in-channel and bring it to attention on the next weekly meeting 14:59:37 <ihrachyshka> otherwiseguy, how so? we don't gate on them 14:59:47 <marun> we can't afford to co-gate, it's a failed strategy 14:59:54 <armax> we have only one minute spare 14:59:56 <markmcclain> in Vancouver we need to discuss extracting out the library bits they need 15:00:02 <armax> markmcclain: yes 15:00:06 <armax> ok, folks 15:00:06 <anteaya> can we include infra in this discussion 15:00:11 <armax> #endmeeting