21:00:23 #startmeeting networking 21:00:24 Meeting started Mon Dec 21 21:00:23 2015 UTC and is due to finish in 60 minutes. The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:28 The meeting name has been set to 'networking' 21:00:31 last meeting in this year? 21:00:47 hello everyone 21:00:51 what about tomorrow's one 21:00:55 hichihara: yes, armax sent an email to the ML 21:01:07 o/ 21:01:09 o/ 21:01:14 mlavalle: Thanks :) 21:01:33 #link https://wiki.openstack.org/wiki/Network/Meetings 21:01:39 #topic Announcements 21:01:43 no meeting next week 21:01:44 hi 21:01:59 you guys have a great holiday break after this meeting 21:02:13 if manjeets is wondering about the drivers meeting 21:02:35 I am fine with hosting it, but at this point I wonder if the other drivers feel the same 21:03:06 i will say make it last one this year 21:03:07 lol 21:03:08 i won't be there 21:03:09 Either way for me. 21:03:16 on a plane 21:03:26 * HenryG has no feelings 21:03:28 i don't want to wake up early. :) 21:03:43 doesn't look like there's anything important to discuss, is there? 21:03:54 well i can catch the first half 21:03:56 HenryG: never ever? 21:03:57 there may be, but is there the will to ;) 21:03:58 salv-orl_: there’s always something imporatnt to discuss 21:04:05 :) 21:04:15 ok, let me sync up with the drivers later on, and I’ll send an email 21:04:17 armax: don't try me or will unleash my yak shaving powers 21:04:34 the drivers team will still review the RFE bugs as usual *cough cough* 21:05:07 and if we don’t meet tomorrow, the ones worth discussing will be discussed the next meeting when we have one 21:05:25 let me remind you that we are approaching M-2 21:05:31 which happens the week of Jan 16 21:05:57 objects in mirror are closer than they appear 21:05:59 altough we have no deadline for RFE submssion/approval, at this point it’s getting clear that anything beefy will have to slip to N- 21:06:00 and the functional tests are failing in the gate so its about 6 or 7 rechecks … so plan ahead 21:06:29 garyk: we should plan ahead to fixing it 21:06:46 I actually wanted to sync up with amuller about it, but let’s take this offline 21:07:04 the Mitaka workload brings me to the next topic 21:07:09 #topic Blueprints 21:07:17 #link https://launchpad.net/neutron/+milestone/mitaka-2 21:07:35 garyk: is someone working on whatever is causing that? 21:08:02 dougwig: i am not sure. 21:08:09 dougwig: tehre’s a cluster of random failures that puts the total failure rate to something unberable 21:08:17 from the patches i have seen it is HA and restart tests 21:08:33 just noticed, looks like the job climbed to around 35% failure over the last day 21:08:38 that's un-good 21:08:56 we have a tag that collects the functional failures together 21:09:03 I have a patch for one failure https://review.openstack.org/#/c/257284/ 21:09:12 we can discuss this during the bugs section 21:09:51 as for blueprints/rfe 21:09:58 we have a number of them that haven’t even started 21:10:09 or have unmrged specs 21:10:28 those will be the first one to be pruned out 21:10:40 so bear that in mind 21:10:48 by pruned do you just mean retargeted? 21:10:54 one it caught my attention was 21:11:09 kevinbenton: yes, apologies for my poor choice of words 21:11:13 #link https://blueprints.launchpad.net/neutron/+spec/add-tags-to-core-resources 21:11:19 this has been sittling idle for a while 21:11:32 I talked to Gal, who is currently the drafter/assignee 21:11:39 or I shall say, was 21:11:49 and he said he can’t focus on it anymore 21:11:58 garyk you were the approver 21:12:00 but I removed you 21:12:10 since you haven’t done such a great job at spotting the stall 21:12:11 armax: ok. 21:12:20 so this one it’s up for grabs 21:12:39 if someone wants it, I think we still have time to tackle it for Mitaka, otherwise it’s out 21:12:50 armax: seems like you have the time so go ahead and implement it 21:12:56 * sc68cal thinks if there is doubt - push to N 21:12:59 i think we should revist after the break 21:13:20 if someone is interested, please reach out 21:14:03 tumbleweed... 21:14:22 let me remind people who have BP assigned to them in one capacity or another, that’s it’s important to make sure progress is made on a weekly basis 21:14:29 for that spec it is good to point out that it was something needed by kuryr 21:14:44 if gal cannot work on it anymore, maybe it is not a piority anymore for kuryr? 21:14:56 i don't think it ever was a priority for kuryr 21:14:59 regardless 21:15:02 i believe it was driven by TriCircle 21:15:40 russellb: at some point I believe kuryr developers wanted to attach tags to resources managed by that docker driver, but if there is another consumer then it's another story 21:15:45 The blueprint process is outlined here: 21:15:46 http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements 21:15:55 and explains prioties and assignments 21:16:13 the tags one was low from a Neutron point of view 21:16:18 ok, let’s move on 21:16:22 #topic Bugs 21:16:35 salv-orl_: ah yes, you're right, a use case came up there too 21:16:55 carl_baldwin: you’ve been the custodian for the week 21:17:03 russellb: but anyway armax bestowed the table of the law upon us and made our discussion pointless 21:17:09 Yes, I think it was pretty quiet. 21:17:23 salv-orl_: did you eat the oxford dictionary this morning? 21:17:39 I do recall a couple of critical but I think they were taken care of... 21:17:40 15 commandments! - 10 commandments! 21:17:42 the functional job has been acting up 21:17:54 I noticed that the linuxbridge went nuts for a little while too 21:18:06 https://bugs.launchpad.net/neutron/+bug/1526675 21:18:06 Launchpad bug 1526675 in oslo.db "test_models_sync fails with 'Models and migration scripts aren't in sync'" [Critical,In progress] - Assigned to Ann Kamyshnikova (akamyshnikova) 21:18:06 we should try and keep an eye on these 21:18:10 ... and ... 21:18:10 armax: that peanut butter had an unusual flavour indeed 21:18:23 dvr went voting again 21:18:26 kudos to the team 21:18:34 who worked hard to bring it in check 21:18:51 This one still marked critical: https://bugs.launchpad.net/neutron/+bug/1527483 21:18:51 Launchpad bug 1527483 in neutron "VPNaaS - No providers specified for 'VPN' service" [Critical,Confirmed] - Assigned to Martin Hickey (martin-hickey) 21:19:05 armax: hah, that's good news. Good work! 21:19:25 I'm not sure this one should be marked critical. 21:19:54 carl_baldwin: that’s the fallout for https://blueprints.launchpad.net/neutron/+spec/autogen-neutron-conf-file 21:20:01 I was expecting something like this would happen 21:20:28 I believe mhickey is asleep now 21:21:00 the change he proposed https://review.openstack.org/#/c/259385/ 21:21:16 makes me wonder what’s the latest on revising this are of devstack 21:21:35 I’ll follow up with sc68cal but for now, perhaps we should try to reach out to other devstack cores to have it nudged in? 21:21:41 *area 21:21:50 * sc68cal looks 21:22:00 I can +2+A that 21:22:10 sc68cal: cool 21:22:15 sc68cal: Thanks! 21:22:39 carl_baldwin: anything else, before we spend a few words on 21:22:39 That's all, I think. 21:22:40 #link https://bugs.launchpad.net/neutron/+bugs?field.tag=functional-tests&orderby=status&start=0 21:22:41 sc68cal: is now devstack core 21:23:02 sc68cal: congrats!? 21:23:15 for the functional tests it looks like test_restart_l3_agent_on_sighup is the main culprit. Anyone know if there's a bug on this? 21:23:19 let me just read over the patch a bit and see what reviewers say. 21:23:23 sc68cal: congrats! 21:24:09 amotoki is the next bug deputy. I see he has already been active. 21:24:14 I don't see a bug tagged with functional-tests or gate-failure for that, I'll file one and look in to it 21:24:15 i've seen whenever jenkins failed est_restart_l3_agent_on_sighup was culprit 21:24:31 amuller: are you referring to this one? 21:24:34 bug https://bugs.launchpad.net/neutron/+bug/1518921 21:24:34 Launchpad bug 1518921 in neutron "Functional tests failing inside _test_restart_service_on_sighup with "Timed out waiting for file /tmp/XXX/YYY/test_server.tmp to be created and its size become equal to ZZZ"" [High,In progress] - Assigned to Sreekumar S (sreesiv) 21:25:37 armax: oh yeah, looks like it 21:25:40 thanks 21:25:55 I'll rename it... 21:26:00 amuller: do you know of anyone who watches the reliability of the functional job? 21:26:18 armax: no, and I don't pro-actively monitor it myself 21:26:26 maybe I should have it as my background :( 21:26:39 I wonder if we should explore the idea of having job sponsors :) 21:27:05 we already implicitly do 21:27:16 I don't know if we should formalize every bit of how we work 21:27:33 amuller: yeah, we can punch cards for it 21:27:41 amuller: we do it very poorly though 21:27:50 and get a weekly report :) 21:28:06 Testing Progress Status 21:28:11 or TPS for short 21:29:14 I am fine either with or without an official person, but at a 35% failure rate I can’t imagine we’re squashing nearly quick enough 21:29:23 * HenryG recognizes the Office Space reference 21:30:31 anyhoo, something to mumble on 21:30:49 or an automated monitor, maybe. 21:31:01 gate jobs demand to be treated like blueprints 21:31:06 in the end if the functional job gets in the way rather than helping, trust will be lost 21:31:10 they're tired to be considered 2nd class citizens 21:31:14 and the end of the world will be in sigh 21:31:15 sight 21:31:28 you all have been WARNED!! 21:31:39 reedeem yourselves before it’s too late 21:31:40 dougwig: like a bot that spits out a warning on this channel when a voting job gets above a threshold 21:31:49 or sends an email to interested parties 21:31:54 amuller: that would be cool 21:32:00 yes, or an email. because i don't tend to just scan dashboards regularly. 21:32:02 kevinbenton: an idea for infra... 21:32:02 i like in channel notices 21:32:06 armax: you were going to spread holiday joy during this meeting, not gllom 21:32:09 gloom^ 21:32:16 oops sorry 21:32:19 I got carried away 21:32:36 * armax puts the santa’s hat on again 21:32:57 ok for now, we have a bunch of fixes targeted 21:33:13 so if we can get some of those in shape for merging…that would be a good first step 21:34:13 this week is amotoki’s turn for deputy 21:34:31 anyone brave enough to volunteer for the week of Dec 28 21:34:34 ? 21:35:05 o/ 21:35:17 kevinbenton: I noticed you never did it 21:35:20 I'm on PTO the week of the 28th but I can do the next week 21:35:26 do I see you raising the hand? 21:35:29 yes 21:35:42 #action amuller: for the week of Jan 4th 21:35:42 * salv-orl_ kevinbenton is the usual blackleg 21:35:57 #action kevinbenton deputy for the week of Dec 28th 21:36:03 * amuller writes himself a reminder 21:36:08 salv-orl_: follow the example! 21:36:18 instead of making such remarks 21:36:22 :) 21:36:28 armax: never! The resistance shall never die!!!! 21:36:37 salv-orl_: and we all love you for it 21:36:39 next section 21:36:44 #topic Docs 21:36:53 salv-orl_: resistance is futile 21:36:55 emagana 21:36:57 udere? 21:37:03 I don’t see Sam-I-Am 21:37:09 armax: Yes, I am 21:37:36 We had our IRC meeting last Thursday to start defining what is left to remove the WIP for the networking guide 21:38:06 We have an etherpad to do the assignments. #link https://etherpad.openstack.org/p/networking-guide 21:38:25 We need help on the topics marked as (H) - High priority 21:38:51 * armax looks 21:39:06 on other areas sc68cal made a good progress on the versioning for the networking guide 21:39:16 emagana: we also have bugs filed against the neutron launchpad project 21:39:24 we god an agreement for OVN related staff, so we are good 21:39:54 armax: we should move those bugs from neutron to openstack-manuals repo 21:40:06 armax: do you want me to do that? 21:40:22 can we just add openstack-manuals? I'd rather keep it linked to neutron 21:40:26 emagana: no 21:40:42 sc68cal: that's a better idea 21:40:43 emagana: I have a patch up 21:40:46 #link https://review.openstack.org/#/c/253229/ 21:41:04 that will automatically tag bugs filed by the openstack-infra bot with doc 21:41:19 armax: nice! 21:41:37 emagana: some bugs apply to neutron’s devref 21:41:49 emagana: others will target api-site and openstack-manauls 21:41:56 armax: sounds good. 21:41:59 emagana: I think the vetting needs to be done on a case by case basis 21:42:23 armax: I can review the ones that are for manuals just to confirm and looking for volunters 21:42:24 emagana: until neutron becomes part of defcore, the bugs will keep on being filed against LP Neutron 21:43:46 emagana: anything else? 21:44:20 link to our meetings is here #link https://wiki.openstack.org/wiki/Documentation/NetworkingGuide/Meetings 21:44:23 armax: nothing else 21:44:44 ok cool 21:44:46 thanks 21:44:55 #topic Open Discussion 21:44:58 #link https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda 21:45:09 haleyb_ raised an item for discussion 21:45:21 I replied inline since he said he might not be around 21:46:04 I personally think the issue is easy to resolve, as two competing approaches to the same problem seem counterintutive, and we should favor obondarev’s pursued approach 21:46:26 i am going to crash. sorry. happy holidays to all. take care 21:46:27 anything else you might want to discuss, like a coup d’etat to remove your PTL? 21:46:39 garyk: happy holidays! 21:46:51 garyk: happy holidays 21:47:13 armax: what did haleyb_bring up? 21:47:16 * armax wished he would be deposed 21:47:39 kevinbenton: you want the TL;DR version? 21:47:45 armax: ye 21:47:53 kevinbenton: ok 21:47:58 armax: with all due respect, if there was a coup it was hardly being discussed in public 21:48:16 kevinbenton: when agents talk to servers at scale, rpc call may time out because of a huge payload being processed server side 21:48:27 salv-orl_: we’re open source! 21:48:29 but if you see a tank in your driveway and it's not yours, well, maybe that's it 21:48:53 kevinbenton: so one approach that’s been touted for a while is to chunk up the payload and issue multiple rpc calls 21:48:59 salv-orl_: lol 21:49:05 armax: There was a discussion on the nova - neutron communication for the live migration. This is being discussed currently in the bug shown below. #link https://bugs.launchpad.net/neutron/+bug/1456073 21:49:05 Launchpad bug 1456073 in neutron "Connection to an instance with floating IP breaks during block migration when using DVR" [High,Confirmed] 21:49:22 armax: I would like the cores opinion on this before we proceed. 21:49:27 Swami: ok, I’ll look into it 21:49:33 armax: thanks 21:49:40 Swami: plz bring it to the attention for next meeting so that we don’t forget 21:49:51 armax: Ok will add it to the agenda. 21:49:56 kevinbenton: you with me or shall I go on? 21:50:09 armax: well i know chunking was one approach 21:50:13 armax: what is the other? 21:50:22 kevinbenton: the cruz of the matter is the chunk size 21:50:37 kevinbenton: one approach makes config driven, the other makes it dynamic 21:51:04 armax: i see 21:51:56 ok, if there’s nothing else you guys would like to discuss… 21:52:20 let’s spread joy and holiday spirit 21:52:31 armax: will do :-) 21:52:43 let’s get recharged and ready for the final sprint! 21:53:23 happy holiday everyone! 21:53:27 #endmeeting