21:00:10 #startmeeting networking 21:00:11 Meeting started Mon Mar 21 21:00:10 2016 UTC and is due to finish in 60 minutes. The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:16 The meeting name has been set to 'networking' 21:00:19 let’s see how sleepy we are today 21:00:33 it’s the beginning of spring 21:00:35 o/ 21:00:40 On the dot 21:00:44 o/ 21:00:47 o/ 21:01:09 o/ 21:01:09 hello 21:01:11 o/ 21:01:18 armax: a chilly beginning of spring in Texas. It was 38 this morning in San Antonio 21:01:52 mlavalle: it’s rainy and cold in this part of the world too 21:02:00 mlavalle glad you are still in San Antonio and not Houston 21:02:14 San Diego is nice as always :-) 21:02:15 everybody's glad they're not in Houston. 21:02:26 +1 21:02:27 aloha 21:02:45 let’s dive in so that we can all go back and hibernate 21:02:45 I'm glad I'm not in Houston 21:02:55 hi 21:03:00 #topic Announcements 21:03:27 We have an RC1 and we’re working towards an RC2 21:03:52 o/ 21:04:07 please test the release and for any issue that you find, file a bug report and tag it with mitaka-rc-potential 21:04:10 #link https://bugs.launchpad.net/neutron/+bugs/?field.tag=mitaka-rc-potential 21:04:28 right now we look RC bug free 21:04:47 * HenryG joins late 21:04:49 we’ll pull the trigger on RC2 in the next day or so 21:05:05 if you are rc bug free why do you need an rc2? 21:05:08 if no other bugs are found, this would be our Mitaka release 21:05:28 anteaya: we had bugs targeting RC2 that were fixed post-rc1 21:05:33 ah thanks 21:06:05 #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/089701.html 21:06:20 this is the reminder email from the release team 21:06:55 the deadline for release candidates is Mar 28 21:07:29 having said that, Newton is open for business 21:08:10 before we dive into it though, please review https://review.openstack.org/#/c/286413/ to make sure we haven’t misrepresented anything 21:08:39 I’d like to get that merged before we can open up the specs repo for Netwon efforts 21:09:16 this actually brings me to the next point, which is: bump all targeted specs to the newton directory 21:09:18 #link https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z 21:10:05 nice idea on the post mortem 21:10:25 thanks 21:11:50 The summit is a little over a month from now 21:12:11 I have sent out an email to ask for design summit ideas 21:12:20 please collect your thoughts on https://etherpad.openstack.org/p/newton-neutron-summit-ideas 21:12:32 we’ll keep the design format similar to last year 21:12:48 and I’ll work with the drivers team to put together an agenda once we have enough feedback 21:13:05 is someone looking at other project etherpads for adding neutron sessions were appropriate? 21:13:21 I know nova's etherpad has a neutron section 21:13:40 anteaya: do you happen to have a link handy? 21:13:45 I looked at the nova etherpad 21:13:59 dougwig: https://etherpad.openstack.org/p/newton-nova-summit-ideas 21:14:01 awesome thanks 21:14:03 :) 21:14:24 When is dead line for the ideas? 21:14:27 I don't know if cinder and keystone and such have their planning etherpads up yet 21:14:34 hichihara: depends on the project 21:14:44 hichihara: no deadline per se, but we’d want to finalize the schedule in the next couple of weeks 21:14:45 armax : I added couple of ideas to the etherpad 21:14:57 Thanks 21:15:14 there is a deadline from ttx and thingee to have them up for everyone, but every project does it a bit differently 21:15:17 hichihara: as soon as I learn more from ttx and thingee will inform the team 21:16:03 typically the deadline is hinted by when the summit webside is online and we can start filling in the sessions 21:16:15 armax : We are looking to setup a joint session for Ironic/Nova/Neutron for Vlan Aware VMs for baremetal deployments 21:16:43 Sukhdev: ack 21:17:14 Sukhdev: knowing that we don’t even have an implementation for virtual trunking…I can’t help myself but giggle a little 21:17:43 Sukhdev: but yes, I think we’d want to start that conversation 21:17:51 We probably want to continue the tradition of the bi yearly Friday vlan aware VMs meetup 21:17:57 armax : ha ha - but, sooner we sync up sooner we will make sure we do not drift apart in implementation 21:18:00 Sukhdev: only for vlan aware VMs? the joint session sounds helpful. it can cover various topics around ironic/neutron/nova 21:18:16 amotoki : +1 21:18:18 Sukhdev: yes, we’d want to confirm the model is sound across all the flavors of provisioning we can come up with 21:19:00 Sukhdev: we should probably drop the VMs from the title as Apple dropped Computer back in the days 21:19:09 but I digress 21:19:24 armax : +1 on both counts :-) 21:19:50 I hope this cycle is the cycle where we can get closure on vlan trunking 21:19:51 Vlan aware servers 21:20:09 but we’ll get to that 21:20:27 I thought some of the implementation is already underway from the neutron side 21:20:56 in fact, in the next few days I suggest anyone who’s got backlog items to make sure they get ready into shape by Newton-1 21:21:09 Sukhdev: we got some patches up for review but nothing has merged yet except the spec 21:21:26 which we’ll have to be reproposed for Newton 21:21:58 armax : there are few patches on Ironic side as well - and they are fairly apart from each other - hence, we should have joint session so that we can coverge 21:22:09 I’ll set up our next team meeting to go over the blueprints/rfe that didn’t make Mitaka 21:22:43 any other reminder/announcement from the team? 21:24:26 ok 21:24:55 #topic bugs 21:25:15 this past week we had hichihara as our deputy 21:25:22 Yeah 21:25:30 I have saw new 6 Critical bugs and some High bugs with mitaka-rc-potential. 21:25:32 hichihara: thanks for volunteering, is there anything you’d like raise? 21:25:40 The critical bugs were finished now. 21:25:50 and also all bugs with mitaka-rc-potential have been finished. 21:25:56 That's all :) 21:26:00 yup, there’s more with the backport-potential tag 21:26:06 yes 21:26:12 https://bugs.launchpad.net/neutron/+bugs?field.tag=mitaka-backport-potential 21:26:12 #link https://bugs.launchpad.net/neutron/+bugs/?field.tag=mitaka-backport-potential 21:26:28 oh...sorry duplicate ;) 21:26:28 ihrachys : can i bring up one bug which is in Mitaka RC-1, but is hitting kilo as well 21:26:51 there are probably not release critical but worth a quick land to stable if we manage to nail fixes in master 21:26:52 Sukhdev: ? 21:26:52 ihrachys : and it is not back ported yet 21:27:01 Sukhdev: link? 21:27:11 #link: https://bugs.launchpad.net/neutron/+bug/1551542 21:27:13 Launchpad bug 1551542 in neutron "need to check if a plugin's start rpc listeners is supported before trying to start it" [Medium,Fix released] - Assigned to Brandon Logan (brandon-logan) 21:27:25 https://review.openstack.org/#/c/286384/ 21:27:55 This is in RC-1, but, Mirantis distros are hitting in Mirantis release 7.0 - which is Kilo 21:28:33 Sukhdev: i think it is backport-able, but kilo stable update has different schedule 21:28:49 Sukhdev: ok, what stops us from backporting? 21:29:00 Sukhdev: note that kilo will be soon closed after mitaka releases 21:29:14 ihrachys : nothing, really :-) 21:29:19 I thought kilo is security fixes only 21:29:29 +1 21:29:35 IIRC security fix or critical fix 21:29:41 armax: and high impact stuff. so it depends on bug details. 21:29:47 ihrachys : I was hoping some Mirantis guys will jump in :-) 21:29:51 ihrachys: ack 21:30:14 ihrachys: this doesn’t look critical to me 21:30:22 honestly, does not seem high impact. but let's just discuss in gerrit. 21:30:31 yup 21:30:42 Mirantis can always backport into their MOS or however they call it 21:30:43 thanks Sukhdev for raising the issue 21:30:52 armax: The base class is changed - and fails many plugins to even initialize - so, figure the criticality 21:31:16 Sukhdev: but how is it possible that’s being broken for 3 releases? 21:31:45 armax : good question - even I was scraching my head when customers reported it :-) 21:31:52 Sukhdev: maybe the issue has been misrepresented, that said, at this point let’s get eyes on this 21:32:09 armax : agree 21:32:32 IIRC it is reported as an error, but most plugins succeed to start 21:32:39 apart for this, we need a new volunteer for next week 21:33:08 any takers? 21:33:48 i can volunteer 21:34:03 * Sukhdev three cheers for amotoki 21:34:03 is it for this week? 21:34:05 thanks amotoki 21:34:18 #action amotoki bug deputy for week of Mar 28 21:34:53 Who is bug deputy in this week? 21:34:59 we don't see any bug duputy for this week 21:35:20 hichihara: you’re right 21:35:27 hichihara: I overlooked 21:35:45 hichihara: any other taker? if not, I’ll fill in 21:36:07 I can do this week. 21:36:16 HenryG: attaboy 21:36:26 #action HenryG deputy for the week of Mar 21 21:36:29 thanks HenryG 21:36:42 Everyone take a week off. :D 21:36:42 I would like to raise https://bugs.launchpad.net/neutron/+bug/1430003 21:36:44 Launchpad bug 1430003 in neutron "Corrupt POSTROUTING Chain when using Metering and VPN agents together" [High,Confirmed] - Assigned to Yi Jing Zhu (nick-zhuyj) 21:37:05 it seems metering-agent and vpn-agent cannot be used 21:37:28 we don't have a fix for this, but it is worth mentioned in our release note 21:38:14 * armax looks 21:38:59 the order of iptables chains is randomely swapped... and it leads to unexpected behavior. 21:39:37 if this issue is there since icehouse…oh boy 21:40:01 I found this last week :( 21:40:07 that’s even worse than the kilo issue that Sukhdev raised 21:40:13 iptables need some serious redesign we also run into issues from the FWaaS side 21:40:36 combination of two services - probably never were tested together :-) 21:40:45 Sukhdev: yup 21:41:05 not the most popular services 21:41:15 yeah, and iptables/chains don’t have a good plugin model 21:41:34 do we even have expertise in the metering agent anymore? 21:41:57 I have got the impression that’s a limb we’re waiting to cut off 21:42:35 yeah... it might be better to apply iptables rules from one agent... 21:42:45 armax: i feel the same. 21:42:49 this is the usual dilemma, if we don’t have enough people who care about the quality of a piece of the puzzle… 21:43:12 well, I see some interest in it expressed on ops@, so it's not like we can easily drop it with no complains 21:43:31 ihrachys: I was not going to drop it willy nilly 21:43:44 we really wanted to use the metering agent 21:43:48 ihrachys: but if we have no-one maintaining it, then we can’t ship something that’s broken eitehr 21:44:08 but it made us miserable, so we ended up dropping it for custom metering outside openstack. 21:44:17 at least we need to mention this in 'known issues' to avoid more people try this in the initial mitaka. 21:44:28 +1 21:44:33 amotoki: +1 21:44:34 they shouldn't step on each other since there is a lock, but there is no way for the agents to know the order each prefers it's rules in (i'm guessing that is the issue) 21:44:55 yep, hence my comment for a sane plugin model 21:45:02 amotoki: can you file a release note? I’ll make sure we include it in rc2 21:45:05 hinting at a bigger neutron problem 21:45:13 armax: sure 21:45:20 amotoki: thanks 21:45:53 I actually wondering why the metering agent needs to fiddle with iptables 21:46:06 but that tells the amount of knowledge that I have on the metering piece 21:46:10 armax: packet/byte counts 21:46:11 armax: it counts traffic via iptables counters. 21:46:16 xgerman: neither we have any proper plugin point for ovs flows. it's quite a common issue throughout components. 21:46:23 metering agent needs to setup iptables rule to count traffic per iptables granurality 21:46:36 right, but that’s pretty invasive 21:47:15 yes 21:47:27 ihrachys yep hence my desire for a better way... 21:47:38 we mihgt need to explore a different approach for iptables 21:48:02 It is tricky two components touch iptables.... 21:48:19 armax: enovance did most of the work, based on the nova-network path done by myself, so blame it on me :) but i think Yi might have an easy fix 21:49:03 haleyb: ack 21:49:08 ok, moving on 21:49:09 i will watch the bug 21:49:24 Sam-I-Am couldn’t make the meeting 21:49:32 so we’ll skip the doc section 21:49:36 but let me remind folks 21:50:02 to make sure documentation is not neglected 21:50:24 we currently have 16 open bugs against docs 21:50:27 #link https://bugs.launchpad.net/neutron/+bugs?field.tag=doc 21:51:16 let make sure we squash these in time for the release 21:51:27 we got another two weeks 21:51:42 Sukhdev: i think that bug you highlighted is because MOS back-ported an RPC listener fix that wasn't back-ported upstream 21:52:14 Sukhdev: i.e. it's mainly a MOS bug if i understand correctly 21:52:35 kevinbenton : Thanks for clarifying it for me 21:52:47 Sukhdev: so we good? 21:53:11 kevinbenton : our joint customer is facing this issue - what do you suggest is the best way to address it? 21:53:25 armax : yes, looks like now I am in good hands :-);-) 21:53:26 Sukhdev: file a bug against mirantis openstack 21:53:39 Sukhdev: kevinbenton has very good hands 21:53:40 armax: They are devref only. I guess that we have more doc bugs in openstack-manual and api-site 21:53:50 Sukhdev: https://launchpad.net/~mos-neutron 21:54:13 kevinbenton : Thanks 21:54:16 hichihara: true 21:54:48 ok folks, 5 more minutes, if there isn’t anything burning, I’d give you them back 21:54:53 oh and by the way…it looks like you guys are stuck with me for another cycle 21:55:02 :'( 21:55:07 LOL 21:55:09 you lost your chance to oust me 21:55:32 armax: why would we? 21:55:48 salv-orlando: dunno, you tell me? 21:56:16 bye! 21:56:18 #endmeeting