14:00:44 <mestery> #startmeeting networking 14:00:45 <openstack> Meeting started Tue Jun 30 14:00:44 2015 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:49 <openstack> The meeting name has been set to 'networking' 14:00:55 <hoangcx> Hi all! 14:01:03 <mestery> regXboi:Monday is 7/6 14:01:14 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda 14:01:14 <ihrachyshka_> o/ 14:01:18 <mestery> Like I said, it's packed, so lets get the ball rolling! 14:01:21 <mestery> #topic Announcements 14:01:31 <mestery> #info Liberty-1 was release last week! 14:01:33 <mestery> #link https://launchpad.net/neutron/+milestone/liberty-1 14:01:44 <mestery> Please report bugs using Launchpad if you try out the release tarballs 14:02:03 <mestery> #info The QoS coding sprint is currently ongoing in Raanana Israel 14:02:05 <mestery> #link https://etherpad.openstack.org/p/neutron-liberty-qos-code-sprint 14:02:08 <regXboi> mestery: ack - I see that I'm confused - 7/3 is the observed day 14:02:16 <mestery> regXboi: Yes 14:02:21 <ajo> :) 14:02:35 <mestery> Lets keep moving to try and cull the agenda as much as we can today. 14:02:38 <mestery> #topic QoS Coding Sprint Update 14:02:44 <mestery> ajo: Hi there! 14:02:55 <ajo> hi :) 14:03:18 <ajo> We've been working all day, meeting, thanks to all the contributors that were able to come, and join us remotely. 14:03:24 <mestery> ++ 14:03:40 <lpeer> hi 14:03:43 <ajo> First of all, we submited an amendment to the QoS API spec to make it more consistent 14:03:50 <ajo> #link https://review.openstack.org/#/c/197004/ 14:04:13 <ajo> and we have also submited the code & neutron-client counterparts 14:04:53 <ajo> #link https://review.openstack.org/197078 14:05:00 <ajo> and 14:05:03 <mestery> ajo: Nice work! 14:05:35 <ajo> #link https://review.openstack.org/#/c/189655/ 14:05:42 <annp> hi 14:05:54 <ajo> we had a spec about the OvS agent still open, so , we wanted to ask how to proceed 14:06:18 <mestery> ajo: Link? I suggest we try and prioritize this to get it approved, it's required for QoS so we could approve it or just use devref, your call 14:06:19 <ajo> https://review.openstack.org/182349 (ovs agent spec) 14:06:31 <ajo> mestery we could move it to devref if that's ok 14:06:34 <vikram> hi 14:06:35 <mestery> ajo: ++ 14:06:58 <ajo> probably it makes sense since it's necessary to have a reference for the API :) 14:07:14 <mestery> ajo: ++ 14:07:16 <ajo> there are a few patches on flight, if anybody has time, here's the link for the topic: 14:07:24 <ajo> https://review.openstack.org/#/q/topic:neutron-qos,n,z 14:07:32 <mestery> #info QoS OVS agent spec to be moved to devref as part of implementation 14:07:44 <mestery> #link https://review.openstack.org/#/q/topic:neutron-qos,n,z QoS patches review link 14:08:01 <ajo> any review time is appreciated 14:08:09 <ajo> also, 14:08:23 <ajo> an important note, is that we're a bit abusing armax callback mechanism 14:08:30 <mestery> :) 14:08:40 <ajo> under his permission, with a long term goal of extending it's API when dealing with resource extensions 14:08:58 <ajo> he has something in mind and he will do it, while we abuse his current implementation to avoid blocking us :) 14:09:31 <ajo> I wasl talking about this: https://review.openstack.org/#/c/193585/ 14:09:32 <mestery> ajo: OK, make sure to keep armax in the loop here going forward please 14:09:43 <ajo> mestery, of course 14:09:52 <mestery> Cool 14:10:01 <ajo> Anything I'm missing? 14:10:03 <ihrachyshka_> and yeah, please fix gate ;) 14:10:07 <mkolesni> ajo: https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:feature/qos,n,z 14:10:09 <ajo> (asking to the participants) 14:10:13 <ajo> ihrachyshka_: lol 14:10:29 <mestery> :) 14:10:44 <mestery> Thanks for the update ajo! Now, please take the QoS team out for a team dinner :) 14:10:48 <vikram> ajo: you have covered everything :) 14:10:50 <ajo> mestery: I think it's all, I will send some links to pictures in some minutes, but let's not block the meeting anymore 14:11:01 <mestery> ajo: Thanks, we'll move along then. :) 14:11:05 <lpeer> mestery: it is being taken care of 14:11:14 <mestery> lpeer: Excellent! :) 14:11:15 <mestery> #topic Bugs 14:11:23 <mestery> We have a number of bugs I wanted to highlight this week 14:11:37 <mestery> #topic https://bugs.launchpad.net/neutron/+bug/1465434 14:11:38 <openstack> Launchpad bug 1465434 in neutron "DVR issues with supporting multiple subnets per network on DVR routers - PortbindingContext does not have the status." [Critical,Confirmed] - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan) 14:11:44 <mestery> This one is why DVR hasn't worked in the gate for weeks now. 14:11:52 <mestery> Swami is on this, his patch listed there could use reviews 14:12:04 <mestery> We need to get DVR stable again and get the DVR job running and the multi-node job 14:12:13 <mestery> yamamoto: If you have time, can you review this one please? 14:12:24 <mestery> haleyb: Also your review needed here :) 14:12:25 <yamamoto> sure 14:12:33 <haleyb> yes, will look 14:12:35 <mestery> Thanks! 14:12:37 <mestery> Next up 14:12:49 <mestery> https://bugs.launchpad.net/neutron/+bug/1465837 14:12:49 <openstack> Launchpad bug 1465837 in neutron "Linux bridge: Dnsmasq is being passed None as an interface" [Critical,New] - Assigned to Sean M. Collins (scollins) 14:12:53 <mestery> sc68cal: This one looks to be yours :) 14:12:59 <sc68cal> yup 14:13:08 <mestery> How is it coming? I know you were at the mid-cycle last week 14:13:17 <sc68cal> I've also seen some race conditions in the linux bridge job around network deletion and port binding (I think) 14:13:30 <mestery> Cool! I saw an agenda item later in the meeting for that 14:13:38 * beagles wanders in late 14:13:47 <ihrachyshka_> mestery, we're eager to get something to digest, if anything, reviews please 14:13:49 <sc68cal> We're at the point where we can actually run all the tests, but it does appear that the linux bridge mechanism driver needs some attention 14:14:07 <sc68cal> we've got a couple bugs that I plan on opening and filling in details about, based on what I'e seen from experimental runs 14:14:23 <sc68cal> if anyone is interested in helping please let me know 14:14:30 <mestery> sc68cal: OK, that sounds fine, when you do, feel free to add a section to the weekly agenda here 14:14:37 <sc68cal> mestery: well do 14:14:42 <sc68cal> *will 14:14:44 <mestery> #info sc68cal to file some bugs around the rough edges of the Linuxbridge ML2 driver 14:14:45 <mestery> Thanks sc68cal 14:14:47 <mestery> Up next 14:14:59 <mestery> https://bugs.launchpad.net/neutron/+bug/1359523 14:14:59 <openstack> Launchpad bug 1359523 in neutron "Security group rules are erroneously applied to all ports having same ip addresses in different networks" [High,In progress] - Assigned to shihanzhang (shihanzhang) 14:15:18 <mestery> Looks like a partial fix for this one merged 14:15:21 <mestery> A while back 14:15:44 <mestery> We discussed this 3 weeks back, and not much has happened since. 14:15:59 <mestery> I'll reach out to shihanzhang 14:16:14 <mestery> #action mestery to reach out to shihanzhang on 1359523 14:16:45 <mestery> https://bugs.launchpad.net/neutron/+bug/1335375 14:16:45 <openstack> Launchpad bug 1335375 in neutron "ping still working after security group rule is created, updated, or deleted" [High,In progress] - Assigned to shihanzhang (shihanzhang) 14:16:48 <mestery> I think the same for this one 14:17:00 <mestery> #action mestery to reach out to shihanzhang on 1335375 14:17:14 <mestery> OK, two more 14:17:15 <mestery> https://bugs.launchpad.net/neutron/+bug/1461172 14:17:15 <openstack> Launchpad bug 1461172 in neutron "neutron.tests.functional.agent.test_l3_agent.MetadataL3AgentTestCase.test_access_to_metadata_proxy times out intermittently" [High,Confirmed] - Assigned to Assaf Muller (amuller) 14:17:32 <mestery> I assigned this to amuller for further triage, but this one looks like a gate issue currently. 14:17:46 <mestery> There was a revert amuller and I ninja merged which I think is related to this failure 14:18:22 <jlibosva> mestery: no, that was related to new fixture 1.3.0 release :) 14:18:30 <mestery> jlibosva: :) 14:18:50 <jlibosva> mestery: ignore me, I thought you;re talking about the bug above :-/ 14:18:52 * jlibosva hides 14:18:57 <mestery> jlibosva: Heh, no that was the one! :) 14:19:02 <mestery> jlibosva: You were right ;) 14:19:07 <mestery> OK, last one: https://bugs.launchpad.net/neutron/+bug/1466663 14:19:07 <openstack> Launchpad bug 1466663 in neutron "radvd exits -1 intermittently in test_ha_router_process_ipv6_subnets_to_existing_port functional test" [Medium,In progress] - Assigned to Sridhar Gaddam (sridhargaddam) 14:19:12 <haleyb> mestery: i looked at that metadata proxy failure last week with henry and got as far as noticing this: "wsgi starting up on http:///:t/" 14:19:29 <mestery> haleyb: Ack, thanks for that! 14:19:46 <haleyb> host was / and port was :t 14:19:58 <mestery> Looks like 14666663 has an assignee and is "In Progress" 14:20:14 <mestery> haleyb: Weird, thanks for digging into it a bit! 14:20:29 <SridharG> mestery: I've submitted patch for the issue - https://review.openstack.org/#/c/193624/ 14:20:45 <mestery> #link https://review.openstack.org/#/c/193624/ Patch for 1466663 14:20:47 <mestery> Thanks SridharG! 14:20:54 <mestery> Any other bugs for the team to discuss? 14:21:44 <mestery> OK, we've got a lot of things to cover, so lets move along 14:21:56 <mestery> #topic Understanding releases for networking-foo projects 14:22:14 <mestery> The tl;dr here is that these repos should follow semantic versioning similar to the server projects 14:22:21 <mestery> #link https://review.openstack.org/#/q/topic:semver-releases+owner:%22Kyle+Mestery%22,n,z 14:22:33 <mestery> I have patches out to fix networking-foo projects which were not doing semantic versioning 14:22:57 <mestery> #info Before doing a release of your networking-foo repo, please talk to mestery so we can coordinate laying down a pre-version tag 14:23:07 <mestery> Also, on the topic of stable branches for networking-foo projects 14:23:22 <mestery> If you want a stable branch, please review this wiki page: https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy 14:23:28 <mestery> And then talk to me and we'll get you one 14:23:44 <mestery> Stable branches for networking-foo repos are nebulous at the moment 14:23:53 <dougwig> This only applies to projects that import neutron or implement one of its plugins, right? 14:23:55 <mestery> I'm working with ttx on this, but for now we'll allow stable branches for these on a request basis 14:23:58 <fawadkhaliq> mestery: great thanks! 14:24:00 <mestery> dougwig: Correct 14:24:18 <mestery> dougwig: Actually, any library under openstack neutron 14:24:44 <mestery> Any questions on networking-foo release or stable branch items? 14:25:45 <mestery> #action mestery to email openstack-dev about networking-foo versioning and stable info 14:25:55 <mestery> I suspect many networking-foo reviewers are not here at this meeting :) 14:25:59 <mestery> OK, lets move along 14:26:05 <mestery> #topic pecan reviews 14:26:14 <mestery> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:feature/pecan+topic:bp/wsgi-pecan-switch,n,z 14:26:35 <mestery> Anyone intersted in reviewing the WSGI switch to pecan, please review those patches 14:26:49 <mestery> I know kevinbenton and blogan would appreciate the reviews 14:27:01 <mestery> We just merged master into feature/pecan yesterday 14:27:41 <markmcclain> I've been working through them 14:27:49 <mestery> markmcclain: Thank you sir :) 14:28:02 <mestery> The sooner we get reviews, the sooner we can fold this work back into master 14:28:09 <yongshenggong_> what drives us to use new branch instead of master directly? 14:28:14 <mestery> Ideally, we would do that in a few weeks to give it some baking time 14:28:24 <mestery> yongshenggong_: Because the work was quite invasive and we wanted to stabilize it there first 14:28:46 <yongshenggong_> mystery, ok got it 14:29:04 <mestery> Any other pecan related questions? 14:29:37 <mestery> #topic Get Me a Network 14:29:44 <mestery> Thanks to haleyb for driving this spec 14:29:45 <mestery> #link https://review.openstack.org/#/c/184857/ 14:29:59 <mestery> I posted a subsequent patch after talking to jaypipes about this. 14:30:02 <mestery> #link https://review.openstack.org/#/c/196803/ 14:30:14 <mestery> I'd encourage jaypipes and mordred to look at htat patch and haleyb's comments there 14:30:26 <mestery> I want to make sure "Get Me a Network" covers what jaypipes and mordred had in mind here 14:30:47 <haleyb> as there has been some confusion i would add 14:30:54 <mestery> haleyb: ++ 14:31:22 <mestery> haleyb: I think your last review comments sums it up nicely, if we can agree on that, then I think we can maybe make it clearer by abandoning my patch and proposing one with your language to make it clearer 14:31:30 <mestery> But again, I'd like jaypipes and mordred to comment at this point 14:31:38 <mestery> Any other questions on "Get Me a Network"? 14:31:55 <haleyb> i'd be happy with #1, so... 14:32:01 <mestery> :) 14:32:32 <mestery> Tough crowd this morning, this meeting must be too serious for most people 14:32:34 <mestery> OK, lets move along 14:32:38 <mestery> #topic Nova VIF Library 14:32:44 <mestery> #link https://review.openstack.org/#/c/193668/ 14:32:52 <mestery> I'd like to highlight this spec in Nova 14:32:59 <mestery> beagles is working to get an exception for this 14:33:03 <mestery> I encourage Neutron folks to review this one 14:33:12 <mestery> sc68cal: Your eyes would be helpful here 14:33:14 <mestery> Among many others 14:33:42 <beagles> feel free to ping me if you have any questions on it 14:33:48 <sc68cal> mestery: yup - took a look and it LGTM 14:33:59 <mestery> beagles: How good are the changes of it getting an exception for Liberty? 14:34:01 <beagles> or just comment on the review :) 14:34:02 <neiljerram> If poss, I'd encourage reviewers not to drown in detail here - just indicate whether or not you support the overall idea, and leave detail to the code review 14:34:14 <mestery> neiljerram: +1000, agree with that sentiment 14:34:40 <beagles> mestery, I've no idea right now. I was going to reach out to john today to make sure I do the right things there 14:34:48 <mestery> beagles: Thank you! 14:34:54 <sc68cal> neiljerram: +++ - I read it mostly for content and it looks good - the overall effort seems reasonable 14:35:17 * sc68cal is saving his paint brush for later 14:35:21 <mestery> lol 14:35:30 <beagles> :) 14:35:31 <neiljerram> :) 14:35:44 <mestery> #topic Linux Bridge CI Job 14:35:47 <mestery> sc68cal: Did you want to discuss this a bit more here? 14:36:20 <sc68cal> mestery: sure 14:37:06 <sc68cal> I've seen some racey behavior in the failure logs - things like a bridge being deleted while a nova boot request is issued 14:37:41 <sc68cal> so I'm going to have to wrap my head around greenlet I guess and figure out why the bridges are being aggressively deleted 14:38:02 <mestery> sc68cal: Sounds like a fun Friday night :) 14:38:37 <sc68cal> if anyone has any experience with the linux bridge mech driver, please don't be shy - otherwise I'll break out git blame and start pinging people :) 14:38:51 <mestery> lol 14:38:55 <sc68cal> since I've got only a couple days worth of experience with the LB agent 14:38:57 <mestery> Thanks for continuing to drive this work sc68cal! 14:39:02 * beagles imagines a wall of shame in the offing 14:39:12 <mestery> :) 14:39:25 <sc68cal> beagles: I doubt that. I think it's mostly that the LB agent never has been put on a really really fast treadmill 14:39:27 <sc68cal> like the OVS agent has 14:39:32 * beagles nods 14:39:35 <mestery> +1 14:39:40 <sc68cal> that's it for me, I yield my time 14:39:56 <mestery> Thanks sc68cal! 14:40:07 <mestery> #topic Flow Classifier Work 14:40:10 <mestery> #link https://etherpad.openstack.org/p/flow-classifier 14:40:14 <mestery> vikram: Did you want to discuss this a bit? 14:40:50 * mestery notes vikram may not be here at the moment but wanted to give him a chance here :) 14:41:01 <mestery> I think we may need to discuss flow classifiers next week 14:41:05 <mestery> #topic Open Discussion 14:41:29 <hoangcx> sc68cal: According to the discussion about "Security Group Logging" spec in the previous meeting. Yushiro has already registered NEW Packet logging API with RFW tags as the following link #link https://bugs.launchpad.net/neutron/+bug/1468366 14:41:29 <openstack> Launchpad bug 1468366 in neutron "RFE - Packet logging API for Neutron" [Undecided,New] - Assigned to Yushiro FURUKAWA (y-furukawa-2) 14:42:20 <xgerman> reviews are needed for: #link https://review.openstack.org/#/c/139758/ 14:42:28 <hoangcx> *RFE 14:42:49 <mestery> xgerman: +100, flavors /cc dougwig 14:42:51 <markmcclain> xgerman: cool.. will add it to the queue 14:43:00 <xgerman> thanks 14:43:14 <john-davidge> reviews also needed for IPv6 Prefix Delegation #link https://review.openstack.org/#/c/158697 14:43:15 <hoangcx> sc68cal: It needs you take a look and help to discuss 14:43:34 <sc68cal> hoangcx: looking 14:44:02 <sc68cal> hoangcx: based on the bug, sounds reasonable 14:44:16 <mestery> #link https://review.openstack.org/#/c/139758/ 14:44:17 <hoangcx> sc68cal: Thanks a lot. 14:44:20 <mestery> #link https://review.openstack.org/#/c/158697 14:44:46 <sc68cal> hoangcx: the question i have is - where will the logged packets be placed? 14:45:03 <sc68cal> how will users of the API retrieve the logs, or view? 14:45:05 <hoangcx> sc68cal: it will be logged to user log file 14:45:55 <sc68cal> hoangcx: what "user log file" ? 14:46:22 <hoangcx> sc68cal: I will make more description about this in the lunchpad 14:46:53 <hoangcx> sc68cal: Do you have any advice for this? 14:47:10 <yongshenggong_> hoangcx: I think it will be implemented in the form iptables -j log action 14:47:22 <hoangcx> Yeah. That's right 14:47:53 <sc68cal> I put a comment in the spec- you need a way to expose this to the user of the API 14:48:01 <sc68cal> my suggestion would be to use the Object Storage API 14:48:05 <sc68cal> that's what it's there for 14:48:30 <sc68cal> could have something like a storage_url - and then they could put a swift URL in 14:48:35 <hoangcx> sc68cal: Sure. Thank you. I will check it and expose 14:49:31 <markmcclain> sc68cal: even then you've now got compute nodes log shipping via swift... not certain how that will sit with some of the more paranoid security environments 14:49:44 <mestery> markmcclain: +100 14:50:21 <sc68cal> true - but if we have a storage_url attribute we can have multiple handlers - swift:// or file:// 14:50:41 <sc68cal> or what hae you 14:50:44 <sc68cal> *have you 14:51:09 <mestery> Lets continue this particular painting on the RFE bug :) 14:51:14 <mestery> OK, thanks folks! 14:51:16 <neiljerram> carl_baldwin is doing interesting and much appreciated work on L3-only networks (https://review.openstack.org/#/c/196812/3). I'd like to thank him for that, and flag this work to anyone else who might be interested in it. (Also, of course, this is mostly being discussed in the L3 subteam, and if you are interested, please go there too!) 14:51:28 <mestery> #link https://review.openstack.org/#/c/196812/3 14:51:34 <mestery> neiljerram: Thanks for the link and reminder there! :) 14:51:42 <pc_m> Anyone tried stacking from scratch with DevStack today using reclone? I'm seeing Horizon failure saying No module i18n. 14:51:44 <carl_baldwin> neiljerram: thanks 14:51:51 <mestery> OK, we'll see you all in #openstack-neutron, the ML, and the internet ;) 14:51:52 <mestery> #endmeeting