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