21:02:12 <mestery> #startmeeting networking
21:02:13 <openstack> Meeting started Mon Jul 14 21:02:12 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:16 <openstack> The meeting name has been set to 'networking'
21:02:26 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:02:38 <mestery> #topic Announcements
21:02:51 <mestery> #info SAD (Spec Approval Deadline) is fast approaching
21:03:02 <mestery> I've begun deferring items to "K" release already, more will likely come.
21:03:24 <mestery> Thanks to salv-orlando for his carpet bombing of the specs reviews today with comments. :)
21:03:38 <mestery> #info SAD is July 20.
21:03:48 <mestery> Any questions on SAD by anyone?
21:03:58 * markmcclain thinks sad might be the best way to describe proposers negatively affected
21:04:09 <mestery> markmcclain: Heh :)
21:04:12 <salv-orlando> mestery: meh no carpet bombing. Comments were as accurate as possible. No reports of civilian casualties.
21:04:41 <mestery> salv-orlando: Seriously, I appreciated your reviews, they were almost identical to my and markmcclain's thoughts on specs as well.
21:04:56 <mestery> OK, next announcement topic.
21:05:04 <mestery> Third Party Meeting CI updates
21:05:14 <mestery> #link http://eavesdrop.openstack.org/meetings/third_party/2014/third_party.2014-07-14-18.00.log.html
21:05:33 <mestery> #info Went over Neutron 3rd Party CI with issues today, hopefully provided a way forward for those affected
21:05:36 <salv-orlando> mestery: still on the SAD topic we should quickly define a process for SAD exceptions, if any. People will want to know if exceptions might be granted.
21:05:38 <mestery> Most CI systems are in good shape.
21:05:53 * mestery weeps at salv-orlando mentioning the exception process.
21:06:10 <mestery> salv-orlando: I will take that as an action item.
21:06:16 <mestery> #action mestery to define SAD exception process
21:06:19 <hemanthravi> mestery: one convergence is failing due to https://bugs.launchpad.net/neutron/+bug/1337698
21:06:20 <uvirtbot> Launchpad bug 1337698 in neutron "q-dhcp agent fails to start on Ubuntu 12.04" [High,Incomplete]
21:06:28 <ijw> Would be nice to be clear what makes some specs candidates for deferral before the SAD, too.
21:07:01 <nati_ueno> hi sorry late
21:07:06 <mestery> ijw: Mostly it's notalready being a part of the Juno Project Plan: https://wiki.openstack.org/wiki/NeutronJunoProjectPlan
21:07:09 <sc68cal> I have a bone to pick with one convergence - we've been having to add lots of skips to the one convergence unit tests due to no ipv6 support
21:07:10 <mestery> nati_ueno: no worries
21:07:20 <sc68cal> perhaps we can discuss in my segment :)
21:07:42 <mestery> hemanthravi: Can you try to attend the third party meeting on Monday's to discuss the issues? Also, the ML and #openstack-infra are filled with helpful people.
21:07:44 * salv-orlando wonder’s what’s the difference between having a bone and having a beef
21:07:46 <mestery> sc68cal: OK, lets do that.
21:07:50 <hemanthravi> mestery: ok
21:07:55 <mestery> hemanthravi: thanks!
21:07:58 <mestery> sc68cal: thanks to you too.
21:08:03 <mestery> One last announcement:
21:08:16 <mestery> Wanted to remind folks the Open vSwitch and Linuxbridge plugins are leaving the tree after Juno-2 is cut next week.
21:08:23 <mestery> Just a heads up, more or less, this is not new information.
21:08:38 <mestery> Any other announcements from anyone?
21:08:54 <nati_ueno> bye bye two plugins..
21:08:56 <mestery> #info Open vSwitch and Linuxbridge plugins will be removed from the tree after Juno-2 releases.
21:09:10 <regXboi> mestery: have the doc folks been told?
21:09:18 * regXboi wonder if doc generation will suddenly break
21:09:32 <mestery> regXboi: I hope not, but we'll soon find out.
21:09:36 <sc68cal> How good is our grenade testing - we've had issues with the OVS->ML2 migrations due to a bug.....
21:09:45 <mestery> regXboi: And emagana is out for today's meeting as well, we'll have to ask him in-channel later.
21:10:00 <markmcclain> sc68cal: grenade is non functional due to the db migration
21:10:09 <mestery> sc68cal: Once we get the DB stuff merged, grenade testing shoudl be full steam ahead.
21:10:16 <mestery> sc68cal: But as markmcclain says, it's not good ATM.
21:10:31 * sc68cal engages 6 point safety harness
21:10:32 <phil_h> doc team is aware the OVS and linuxbridge is being removed
21:10:34 <salv-orlando> mestery: uhm about removing plugins.. just not forget to move away the agents first ;)
21:10:35 <markmcclain> sc68cal: so it masks other problems.. also grenade does no test OVS > ml2 path
21:10:43 <salv-orlando> we need the agents for ML2
21:10:50 <mestery> salv-orlando: ++
21:11:06 <ivar-lazzaro> what about plugins depending from OVS and LB?
21:11:20 <markmcclain> ivar-lazzaro: those plugins will break
21:11:21 <ivar-lazzaro> should they solve the dependency via bug?
21:11:23 <mestery> #info The agents for the Open vSwitch and Linuxbridge plugins will be moved to a new, safer home in the source tree.
21:11:29 <sc68cal> markmcclain: ah - what can be used to test the ovs > ml2 migration?
21:11:43 <salv-orlando> re: grenade and migrations. akamyshnikova has asked to delay until tomorrow morning Moscow time - she has to do some additional checks
21:11:59 <markmcclain> sc68cal: we can look at implementing another grenade scenario
21:12:09 <mestery> markmcclain: ++
21:12:26 <ivar-lazzaro> markmcclain: I thought so, just wondering how much time do they have to fix this, and what's the expected process
21:12:31 <sc68cal> markmcclain: oK - i'll contact you later since Comcast is doing that manually, we'd like to help
21:12:44 <markmcclain> sc68cal: awsome
21:12:57 <marun> sc68cal: the reason there wasn't testing is that the migration script doesn't automate configuration migration, since that's a deployment step
21:13:03 <sc68cal> and by manually, meaning we're just stepping on the landmines as we go
21:13:11 <yamamoto> are they going to be moved out of plugins directory?
21:13:13 <shivharis> any idea which specific file will be removed. Since the respective agents will not be removed...
21:13:26 <mestery> ivar-lazzaro: We've publically indicated the removal of these plugins for a long time now, so hopefully dependent plugins have their plans while underway. :)
21:14:17 * mestery didn't think LB and OVS plugin removal would engender so much discourse.
21:14:23 <mestery> OK, lets move on now.
21:14:40 <mestery> #topic Bugs
21:15:00 <mestery> Our bug czar could not make it, but his report to me included the fact that Ihar's patch has helped with some lock timeout issues.
21:15:10 <ihrachyshka> yay
21:15:14 <mestery> There are some occasional lock timeouts in the gate, but nothing hugely causing problems.
21:15:16 <mestery> ihrachyshka: Thank you!
21:15:17 <otherwiseguy> ihrachyshka++
21:15:23 <ihrachyshka> some? sounds disappointing ;)
21:15:37 <mestery> ihrachyshka: Without bugs, what would we do? ;)
21:15:40 <ajo> some hiden deadlock yet..
21:15:42 <mestery> Any other bugs the team should be aware of?
21:16:00 <ihrachyshka> mestery: if someone shows me remaining locks, I may investigate them separately
21:16:16 <otherwiseguy> mestery: I added a patch for the ofport 'not yet assigned' being treated as a failure bug: https://review.openstack.org/#/c/106517/
21:16:21 <mestery> ihrachyshka: Please sync with enikanorov tomorrow.
21:16:26 <ihrachyshka> kk
21:16:31 <mestery> otherwiseguy: saw that one, thanks!
21:16:33 <salv-orlando> ihrachyshka: enikanorov did that already… search for bug submitted by him.
21:16:44 <mestery> salv-orlando: thanks!
21:16:47 <salv-orlando> enikanorov filed a bunch of bug.
21:16:49 <salv-orlando> bugs
21:17:09 <otherwiseguy> just seemed like it could possibly cause some intermittent test failures.
21:18:15 <mestery> OK, lets move on then.
21:18:19 <mestery> #topic Team Discussion Topics
21:18:27 <mestery> First one: networks without subnets.
21:18:34 * mestery doesn't see beagles here. :(
21:18:40 * mestery does see ijw here. :(
21:18:46 <mestery> ijw: Just kidding. :)
21:18:51 <otherwiseguy> mestery: beagles is unfortunately on vacation.
21:18:52 <salv-orlando> I have a simple comment here. Either we make them work properly or we disallow them.
21:18:54 <ijw> Charmed, I'm sure
21:19:12 * otherwiseguy votes for 'make them work'
21:19:13 * salv-orlando definition of properly is left to community consensus.
21:19:21 <mestery> salv-orlando: ++
21:19:25 <mestery> ijw: Work for you?
21:19:28 <ijw> I don't know what beagles' use case is.  Mine is the standard NFV 'let me send stuff' one, where I'm equally willing to ignore a port address.
21:20:06 <ijw> I have opinions about which way we should do that but overriding issue here is 'let me send stuff' and I'll take anything that does that
21:20:08 <regXboi> well now, that is .... *embarrassing*
21:20:13 <s3wong> lost our chair
21:20:17 <salv-orlando> ijw: “let me send stuff” pretty much means: give me just a l2 transport and get out of the way?
21:20:28 <ijw> Yeah, basically.
21:20:28 <sgordon> ijw, beagles is basically the same
21:20:48 <mestery> My IRC lcient just crashed
21:20:50 <ijw> The presence or absence of subnet is a little bit of a red herring, though it is a bug and it is embarrassing.
21:21:03 <regXboi> mestery: you only missed one line
21:21:05 <rkukura> is provider network with external DHCP a use case?
21:21:05 <thorst> our team also has a use case where we need L2 transport only.
21:21:05 <sgordon> ijw, red herring or not, it worked with nova-net
21:21:11 <ijw> Also we confuse antispoof and secgroups, but that's a fine grained issue we can discuss offline.
21:21:14 <sgordon> ijw, and is what initially ticked them off
21:21:29 <ijw> OK, I hadn't realised that's where beagles was coming from
21:21:38 <mestery> sgordon: If this is a nova parity item, then I suspect we have to support it.
21:21:38 <sgordon> ijw, i think part of beagles' concern is that the net w/o subnet case may slip by the wayside
21:21:44 <mestery> I think it makes sense regardless of that, to be honest.
21:21:51 <sgordon> ijw, as it's a side effect of the current proposals
21:21:54 <ijw> sgordon: The issue is that users rarely intend to do it ime
21:21:55 <sgordon> ijw, rather than part of the intent
21:22:27 <ijw> create net, create vm, oh look I can talk to *everybody*... once I get an address from somewhere...
21:23:12 <ijw> But let's take this up on the ML.  Sorry to go on, but here's probably not the place for detailed discussion.
21:23:20 <mestery> ijw: ++
21:23:28 * markmcclain adds parity item to track
21:23:29 <regXboi> I will point out mestery's point
21:23:30 <mestery> Can we use Brent's thread for this discussion?
21:23:37 <regXboi> if this is a parity item....
21:23:43 <sgordon> mestery, i hope so
21:23:43 * mestery thanks markmcclain for tracking this.
21:23:55 <mestery> sgordon: Lets continue the discussion there. /cc ijw
21:23:56 <sgordon> mestery, part of it was just trying to bring together all the competing proposals in this area
21:24:05 <mestery> sgordon: There are a lot of them, yes.
21:24:33 * mestery suspects this could be the first user of the SPD/SAD exception process ...
21:24:37 <mestery> But I digress.
21:24:48 <mestery> OK, next item is multinode deployment.
21:24:52 <mestery> I am not sure who added this item.
21:25:02 <emagana> mestery: me
21:25:04 <mestery> Ah, looks like emagana.
21:25:09 <mestery> emagana: Hi! :)
21:25:10 <emagana> sorry, in and out of the meeting
21:25:25 <mestery> emagana: No worries, and thanks for highlighting this infra spec here.
21:25:28 <emagana> mestery: I just want guys to comment on the BP.. is WIP and early work
21:25:30 <mestery> I think everyone should review this.
21:25:34 <mestery> emagana: ++
21:25:56 <carl_baldwin> carl_baldwin: will review it.
21:26:04 <emagana> Thanks!
21:26:13 <mestery> Thanks emagana!
21:26:18 <mestery> #topic Nova Parity
21:26:20 <mestery> markmcclain: Hi!
21:26:23 <markmcclain> hi
21:26:29 <markmcclain> lots of work completed last week
21:26:57 <markmcclain> hopefully once we can clear anna's hold we can merge the healing migration
21:27:00 <mestery> It was a good week of working on nova parity indeed.
21:27:06 <mestery> markmcclain: ++!!!
21:27:12 <markmcclain> this will unblock work on enabling grenade
21:27:53 <markmcclain> the dvr folks made good progress and oleg made progress migration
21:28:07 <markmcclain> it was great to get everyone in the same room for heads down hacking
21:28:20 <mestery> It was a great experience for sure!
21:28:22 <carl_baldwin> +1
21:28:39 * mestery notes everyone left before the weather turned in Minnesota as well.
21:28:50 <mestery> Thanks for the update markmcclain!
21:29:03 <mestery> #topic Docs
21:29:06 <mestery> regXboi: Hi there!
21:29:09 <mestery> regXboi: Are you covering this today?
21:29:11 <regXboi> mestery: yo
21:29:12 <regXboi> yes
21:29:36 <regXboi> While I wasn't in MN, I spent part of the week working up from the bottom on the open doc bugs
21:29:47 <regXboi> I've added thoughts/comments/status on them to the wiki page
21:29:53 <regXboi> folks can look and react on the ML
21:30:15 <mestery> regXboi: Thanks!
21:30:38 <regXboi> I plan on continuing up the page as I have time as well
21:30:39 <phil_h> top
21:31:19 <mestery> I encourage folks to read regXboi's notes in detail in the meeting minutes.
21:31:25 <mestery> Thanks for the update regXboi!
21:31:37 <regXboi> welcome
21:31:40 <mestery> #topic Tempest
21:31:41 <mestery> mlavalle: Hi!
21:31:52 <mlavalle> mestery: hi
21:32:20 <mlavalle> my report today is really a summary of what we acomplished last week during the sprint
21:32:37 <mlavalle> we trained two new developers, ohara and Simeon
21:33:15 <mlavalle> with those two developers we were able to write tests for the new LBaaS:
21:33:20 <mlavalle> https://review.openstack.org/#/c/106089/
21:33:34 <mlavalle> https://review.openstack.org/#/c/106462
21:33:54 <mlavalle> Simeon developed a FWaaS / VPNaaS scenario test:
21:33:55 <mestery> #link https://review.openstack.org/#/c/106089/
21:34:01 <mestery> #link https://review.openstack.org/#/c/106462
21:34:12 <mlavalle> https://review.openstack.org/#/c/106473/
21:35:01 <mlavalle> I also had conversations to make sure we are covering DVR and keeping track of the extensions to the API for nova parity
21:35:16 <mlavalle> that's what I have this week
21:36:10 <mestery> Thanks mlavalle!
21:36:15 <mestery> #topic L3
21:36:17 <mestery> carl_baldwin: hi!
21:36:19 <carl_baldwin> hi
21:36:34 <carl_baldwin> Lot’s of great work on DVR last week.  Thanks to those who pitched in.
21:36:45 <carl_baldwin> We worked out some outstanding issues with the patches.
21:36:57 <carl_baldwin> We have a devstack patch that should allow anyone to get a DVR enabled devsatck.
21:37:39 <carl_baldwin> We’ve almost got a Jenkins running tests on DVR enabled code for before merge.  Looking in to making that a gate job (non-voting) for after.
21:37:48 <ajo> nice
21:38:06 <carl_baldwin> We’re can’t merge until after db migration.
21:38:15 <carl_baldwin> er healing.
21:38:29 <armax> carl_baldwin: I explicitely -2 the dvr patches that have db migrations
21:38:35 <mestery> carl_baldwin: Yes, hopefully that merges soon!
21:38:40 <mestery> armax: thanks!
21:38:53 <armax> carl_baldwin: only one is affected by it
21:39:13 <armax> carl_baldwin, mestery: as we need to change the migration_for_plugins variable
21:39:19 <carl_baldwin> After that merges, I think we’re about ready to start merging the first DVR patches.
21:39:25 <carl_baldwin> armax: Thanks.
21:39:51 <armax> but we’ve been seeing quite a turnout of reviews, so I am getting confident that the first set of patches should be ready to land
21:39:57 <mestery> carl_baldwin armax: ++
21:40:03 <carl_baldwin> I’m also starting a list of smaller follow up items to work out during Juno-2 - 3.
21:40:12 <carl_baldwin> HA routing spec merged.
21:40:20 <mestery> carl_baldwin: There was an issue with port binding which rkukura noted, did you two get a chance to talk with armax about that?
21:40:43 <carl_baldwin> mestery: Not yet.  Will soon.
21:40:44 <armax> mestery, carl_baldwin I think there was this patch https://review.openstack.org/#/c/82945/
21:40:57 <carl_baldwin> Oh, right.
21:40:59 <mestery> armax: That's the one
21:41:09 <rkukura> mestery, armax: I’ll start with comments in the review, then we can discuss.
21:41:10 <mestery> rkukura: Is that one ready to merge before DVR? I think that was the plan, right?
21:41:13 <carl_baldwin> Yes, armax had originally brought that to my attention.
21:41:16 <mestery> rkukura: ^^^
21:41:31 <armax> mestery: if we want to let that one in first then we need to review one of the dvr patches
21:41:41 <rkukura> I think that one is ready - just updated today with resolutions to latest comments
21:41:43 <mestery> armax: Yes, that was what rkukura was suggesting I thnk.
21:41:44 <armax> or viceversa, but it shouldn’t be diffcult
21:41:48 <mestery> armax: Thoughts?
21:42:26 <armax> mestery: we could let that one in first
21:42:28 <carl_baldwin> I’ll review that one.  If it is ready then I think we can deal with it.  Otherwise, it has to get behind db healing, dvr, etc.  armax: what do you think?
21:42:44 <armax> carl_baldwin: I’d say db healing first
21:42:56 <mestery> carl_baldwin armax rkukura: OK, lets merge rkukura's before DVR then.
21:43:01 <armax> then between the first set of dvr patches and rkukura’s patch there’s no priority
21:43:07 <rkukura> the ml2 port binding patch doesn’t touch any DB models, so it should be able to get in any time
21:43:11 <mestery> #info Team to try and merge rkukura's patch (https://review.openstack.org/#/c/82945/) before DVR patch.
21:43:22 <carl_baldwin> mestery: rkukura: agreed
21:43:23 <rkukura> mestery: thanks!
21:43:27 <mestery> Great!
21:43:37 <mestery> carl_baldwin: One other thing: The BGP BP was approved today and marked for Juno-3.
21:43:44 <armax> the order is between https://review.openstack.org/#/c/82945/ and https://review.openstack.org/#/c/102101/
21:43:50 <zhhuabj> mestery: sound good
21:43:57 <carl_baldwin> mestery: Great.
21:44:03 <mestery> carl_baldwin: Also, the route order BP.
21:44:16 <carl_baldwin> mestery: Mine?
21:44:23 * mestery looks
21:44:31 <mestery> carl_baldwin: http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/route-order.rst
21:44:38 <mestery> I think that was Zang's
21:44:48 <mestery> carl_baldwin: https://review.openstack.org/#/c/94563/
21:44:48 <carl_baldwin> Oh.  Right.
21:44:48 <salv-orlando> I +2’ed router order bp a while ago. I think it is a low impact one?
21:45:00 <mestery> salv-orlando: Yes, I think so too.
21:45:30 <carl_baldwin> Great.  Should be low impact.
21:45:35 <mestery> carl_baldwin: Lots happening on L3!
21:45:40 <carl_baldwin> Yes, there is.
21:45:54 <mestery> carl_baldwin: Thanks for driving this stuff and leading it!
21:46:08 <carl_baldwin> Glad to help.  That is all I have.
21:46:28 <carl_baldwin> One more:  http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3-agent-responsiveness.rst
21:46:34 <carl_baldwin> ^ That merged and the code is ready.
21:46:43 <carl_baldwin> That is really all I have.
21:46:44 <mestery> carl_baldwin: Excellent!
21:46:46 <mestery> thanks carl_baldwin!
21:46:51 <mestery> #topic IPv6
21:46:53 <mestery> sc68cal: Hi!
21:46:54 <sc68cal> hello
21:47:13 <sc68cal> Most work is currently relying on the radvd patch to land, which needs unit test coverage (https://review.openstack.org/#/c/102648/)
21:47:21 <mestery> sc68cal: ++ to that.
21:48:02 <sc68cal> The other thing I wanted to bring up, is at some point in the future we're going to need to look at 3rd party CI systems and plugins that don't support IPV6
21:48:29 <mestery> sc68cal: Is that something we need to do in Juno, or can we do it in K?
21:48:29 <markmcclain> sc68cal: I think that v6 support should be a must in K
21:48:34 <mestery> markmcclain: ++
21:48:39 <sc68cal> I believe the radvd patch will add another unit test that will need to be skipped in one convergence, since they fail on creating a v6 subnet
21:48:41 <mestery> I think deferring to K is the right thing.
21:49:03 <sc68cal> agree on K deferral, but something to keep in mind, obviously we need to get our house in order first, but it should be shortly
21:49:11 * markmcclain wishes we had declared v6 required for J
21:49:21 <mestery> markmcclain: ++
21:49:39 <sc68cal> I'll be glad to stand up declare it during the summit :)
21:49:48 <mestery> sc68cal: :P
21:49:53 <sc68cal> that's all for me
21:49:59 <ijw_> I think you'd have to define what 'ipv6' was before you could do that - we still keep finding the odd shortcoming
21:50:14 <marun> sounds like something that could benefit from functional coverage, too
21:50:19 <sc68cal> I think we can at least say, you need to allow the creation of an ipv6 subnet
21:50:29 <sc68cal> it may not work, but hey you'll have parity with where we were in Havana and Icehouse
21:50:36 <sc68cal> where it is created then doesn't work ;)
21:50:41 <mestery> marun: ++
21:50:45 <mestery> OK, thanks sc68cal!
21:51:02 <mestery> #info IPV6 support will be required for all plugins in K release.
21:51:04 <mestery> #topic ML2
21:51:06 <mestery> rkukura Sukhdev: Hi!
21:51:16 <Sukhdev> mestery: Hi
21:51:23 <rkukura> go ahead Sukhdev
21:51:29 <Sukhdev> We cancelled the ML2 meeting this week
21:51:42 <Sukhdev> Both rkukura and I were in MN
21:51:46 <rkukura> last week, not this ;)
21:51:59 <Sukhdev> Opps - yes :-)
21:52:17 <Sukhdev> I see few ML2 specs merged this week - thanks to the cores
21:52:31 <Sukhdev> Just as an Info -
21:52:44 <Sukhdev> https://wiki.openstack.org/wiki/Neutron/MigrationFromNovaNetwork/HowTo is the wiki for what we did in MN
21:53:24 <Sukhdev> For the benefit of wider audiance, we had live migration of the VMs from Nova network to Neutron
21:53:37 <Sukhdev> with a 1 sec or outage
21:53:55 <Sukhdev> Thanks to Oleg and Mohammand for their support
21:53:59 <ijw_> Sukhdev: sexy
21:54:22 <Sukhdev> mestery: that is all I have
21:54:29 <Sukhdev> rkukura: want to add anything
21:54:33 <mestery> Sukhdev: Thanks!
21:54:39 <mestery> #topic Open Discussion
21:54:42 <rkukura> nope - we will be meeting this week
21:54:43 <Sukhdev> ijw_: yes, indeed
21:55:06 <nlahouti> a question regarding reviewing code for approved BPs targeted for juno-2. Does it mean all the review should be done by 7/24?
21:55:08 <markmcclain> for those that missed it… the K name poll is still available
21:55:20 <mestery> markmcclain: link?
21:55:26 <markmcclain> #link https://www.surveymonkey.com/s/openstack-k-naming
21:55:36 <mestery> nlahouti: 7/24 is when Juno-2 will be cut.
21:55:36 <ijw_> NFV: we still have an unapproved but high impact VLAN transparent network spec, and I would - if remotely possible - like to get an MTU spec approved.
21:55:56 <mestery> ijw_: Is the MTU spec filed already?
21:56:00 <ijw_> Yup
21:56:00 <mestery> thanks markmcclain!
21:56:15 <ijw_> https://blueprints.launchpad.net/neutron/+spec/mtu-selection-and-advertisement
21:56:29 <ijw_> Even if only the first patches of it get in I'd like to make a try
21:56:50 <mestery> ijw_: I mean, a spec in neutron specs. :)
21:57:01 <ijw_> https://review.openstack.org/105989
21:57:23 * marun fires up a botnet to win the unsecured naming poll
21:57:54 <mestery> OK, thanks everyone!
21:58:07 <mestery> Just a note, I'll be pruning some things out of Juno-2 tonight/tomorrow as well.
21:58:07 <salv-orlando> marun that’s the sequence of words that over irc will be detected by another botnet which will bring the police to your door
21:58:14 <mestery> We have a lot left to land and not much time.
21:58:21 <mestery> Just a heads up if your BP moves to the right a bit.
21:58:24 <marun> salv-orlando: i mean, what's not to like about kleber?
21:58:25 <ijw_> I'm fairly sure you can always find surprising corner cases with MTUs until we do something to fix it properly, and I notice that in small print in the Redhat docs is something saying 'set your guest MTUs to 1400' - which is (a) a copout and (b) also not going to work in certain cases anyway
21:58:39 <salv-orlando> I remember a brazilian footballer by that name
21:59:04 <mestery> See you all on the ML and IRC's. :)
21:59:06 <mestery> #endmeeting