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