21:01:00 <mestery> #startmeeting networking
21:01:01 <openstack> Meeting started Mon Jun  8 21:01:00 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:01 <sc68cal> o/
21:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:05 <openstack> The meeting name has been set to 'networking'
21:01:05 <salv-orlando_> Aloha
21:01:18 <armax> aye
21:01:19 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:01:21 <russellb> hi
21:01:23 <mlavalle> hi
21:01:26 <mestery> Should be a light meeting today (famous last words ...)
21:01:28 <marun> \o
21:01:30 <mestery> #topic Announcements
21:01:46 <mestery> I had an AI to send the ML a note about the new RFE process.
21:01:49 <mestery> So, I did that :)
21:01:50 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-June/066217.html
21:02:03 <mestery> For clarity in the meeting logs:
21:02:04 <mestery> #link http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
21:02:23 <mestery> I had another AI to work with ajo to around QoS development
21:02:31 <mestery> #info Created feature branch (feature/qos) for QoS work in Neutron
21:02:42 <ajo> :)
21:03:00 <mestery> Since our mid-cycles are quickly approaching, I wanted to highlight those again for folks
21:03:01 <mestery> #link https://etherpad.openstack.org/p/neutron-liberty-mid-cycle
21:03:08 <ajo> and ajo landed a first patch out of it #action -> ajo to learn how to use feature branches O:-)
21:03:10 <mestery> #link https://etherpad.openstack.org/p/neutron-liberty-qos-code-sprint
21:03:17 <mestery> ajo: Nice work! :)
21:03:32 <mestery> Any other announcements from anyone for the team?
21:03:33 <ajo> thanks mestery
21:03:37 <dougwig> ajo: make sure to edit the .gitreview in the branch
21:03:49 <mestery> dougwig: Excellent reminder!
21:04:03 <ajo> dougwig, thanks, will do, I guessed it was related to git-review
21:04:33 <Sukhdev> ago, mestery : are there any ML2 related requirements for QoS related work?
21:04:46 <mestery> ajo: ^^^^ from Sukhdev
21:05:08 <ajo> Sukhdev, not yet, we have two interesting plans, but we are not blocked by any ML2 work
21:05:37 <Sukhdev> ajo: cool - this came up in last week's ML2 meeting - hence, wanted to double check
21:05:39 <mestery> Excellent!
21:05:42 <ajo> Sukhdev, we want do develop a generic rpc mechanism for port & net information, in conjunction with a L2 agent extension manager
21:05:50 <ajo> Sukhdev, thanks for asking
21:06:03 <mestery> OK, lets move on to Bugs now
21:06:09 * mestery looks for enikanorov enikanorov__
21:06:10 <mestery> #topic Bugs
21:06:23 <mestery> I cleaned up the bugs agenda a bit on the meeting page
21:06:31 <mestery> And we're left with two bugs we've been tracking on that page for a while now
21:06:37 <mestery> https://bugs.launchpad.net/neutron/+bug/1359523 and https://bugs.launchpad.net/neutron/+bug/1335375
21:06:39 <openstack> Launchpad bug 1359523 in neutron "Security group rules errorneously applied to all ports having same ip addresses in different networks" [High,In progress] - Assigned to shihanzhang (shihanzhang)
21:06:41 <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)
21:06:46 <mestery> Both are interrelated
21:07:12 <enikanorov__> mestery: hi.
21:07:18 <mestery> enikanorov__: Howdy!
21:07:39 <mestery> enikanorov__: We're talking about the two bugs ^^^ above now, they have been High priority for a bit with not much movement it appears
21:07:40 <enikanorov__> mestery: probably i need to step out of bug triage duty
21:07:50 <ajo> question about 1335375, is it after the conntrack work?
21:07:57 <mestery> enikanorov__: OK, lets talk some more on that post-meeting :)
21:08:30 <enikanorov__> 've been busy with other tasks so i don't have enough bandwidth to provide enough info to weekly meetings
21:08:31 <mestery> ajo: Looks to be prior
21:08:36 <enikanorov__> mestery: sure
21:08:41 <mestery> enikanorov__: OK, makes sense, thanks for letting me know!
21:09:00 <ajo> ah, ok :)
21:09:13 <mestery> ajo: Just looking at the age of the bug, etc.
21:09:33 <mestery> Any other bugs the team should be aware of?
21:10:05 <mestery> I'd also like to propose we do a bug triage day next week.
21:10:12 <kevinbenton> 1359523 is horrific because it means security groups have to understand L3 connectivity
21:10:39 <mestery> kevinbenton: "Horrific" is one way to put it
21:10:40 <ajo> I will ask hanzhang about 1335375 status
21:10:59 <mestery> kevinbenton: But your summary seems spot on
21:11:11 <kevinbenton> a.k.a is SG member Y reachable by SG member X
21:11:23 <kevinbenton> which means peaking at routers, etc
21:11:31 <kevinbenton> peeking*
21:11:46 <anteaya> peaking may also apply
21:11:47 <ajo> 1359523 is related, but will be fixed when the tacking information is tied to zones
21:12:08 <ajo> basically both bugs depend on the same set of patches
21:12:15 <mestery> ajo: Are the patches in flight at the moment?
21:12:38 <kevinbenton> ajo: no, it won't be fixed. i'll not waste time during the meeting explaining though
21:12:50 <haleyb> https://review.openstack.org/#/c/118274/ has merged for the first bug
21:12:52 <kevinbenton> ajo: let's chat after
21:12:53 <ajo> kevinbenton, ack, I must be missong some detail
21:12:58 <mestery> kevinbenton: You've piqued my curiosity, please explain why not
21:13:11 <ajo> lol :)
21:13:30 <kevinbenton> mestery: SG1 has members with IP address 1 and IP address 2
21:13:32 <ajo> yes I thought the zones fixed the issue, what's the corner detail I'm missing?
21:13:45 <kevinbenton> mestery: SG2 also has members with IP address 1 and IP address 2
21:13:54 <mestery> kevinbenton: right
21:14:29 <kevinbenton> mestery: SG1 and SG2 each have an address on two disjoint networks
21:14:40 <ajo> hm, ok, I get it
21:14:48 <kevinbenton> mestery: so SG1 is allowing SG2 by accident
21:15:03 <mestery> kevinbenton: yes, that's what the bug summary says.
21:15:08 <ajo> so, the patch will fix the "collisions on connection tracking table" but no the SG collisions themselves by disjoint networks
21:15:14 <kevinbenton> ajo: exactly
21:15:16 <mestery> ajo: sounds right
21:15:34 <ajo> kevinbenton, any mean to fix that case?
21:16:17 <kevinbenton> ajo: yes, basically the security group has to understand that it's not actually capable of connecting to a security group member
21:16:25 <kevinbenton> ajo: so then it doesn't add it to the ipset
21:16:38 <ajo> aha
21:16:51 <kevinbenton> ajo: once we have the concept of address scopes, it would just compare the address scopes of each member
21:16:52 <ajo> yikes, sounds like overcomplicating security groups a lot :/
21:17:02 <mestery> carl_baldwin: That's your queue! ;) ^^^^
21:17:04 <kevinbenton> ajo: and skip any that aren't part of the same scope
21:17:30 <kevinbenton> ajo: but until we have scopes, it has to be inferred by inspecting which routers are attached to each network
21:17:40 <kevinbenton> "horrific"
21:17:44 <ajo> kevinbenton: I agree :/
21:17:46 <carl_baldwin> We might have to take this to the ML.  I’m not sure my head is wrapped around the issue.
21:18:00 <mestery> #action kevinbenton carl_baldwin ajo to continue discussion around horrific SG bugs
21:18:02 <mestery> :)
21:18:11 <mestery> Good idea carl_baldwin
21:18:17 <mestery> Any other bugs to discuss here today?
21:18:19 <ajo> the bug itself is not horrific, the current possible solution is ':D
21:18:26 <dougwig> we need a horrific tag
21:18:31 <ajo> ROFL
21:18:47 <ajo> kevinbenton: thanks for the explanation
21:18:52 <mestery> ajo: agreed
21:18:57 <kevinbenton> right after we add the @skipIfFails decorator for unit tests that don't work
21:19:09 <kevinbenton> ;)
21:19:20 <ajo> :-)
21:19:22 <armax> kevinbenton: +1
21:19:29 <russellb> put that on the global setup for all tests, i like it
21:19:31 <mestery> OK, with no other bugs being bounced about, lets move on and see if we can close this meeting out in (almost) record time!
21:19:40 <mestery> #topic nova-network compatibility tasks
21:19:42 <ajo> no more failing tests, finally!
21:19:55 <mestery> Mostly here, I just wanted to highlight the "get me a network" patch and see if anyone has taken this up yet
21:19:57 <russellb> i put up 4 patches this afternoon that lead up to the rolling upgrades test job
21:20:00 <mestery> #link https://review.openstack.org/#/c/184857/
21:20:05 <mestery> russellb: Yay!
21:20:06 <russellb> all patches linked from the etherpad
21:20:10 <mestery> russellb: Thanks so much, that's awesome!
21:20:24 <amuller> russellb: wow, awesome
21:20:35 <russellb> we'll see if it works :)
21:20:39 <mestery> :)
21:20:43 <ajo> where's etherpad? :)
21:20:52 <russellb> https://etherpad.openstack.org/p/YVR-nova-network
21:20:53 <mestery> #!link https://etherpad.openstack.org/p/YVR-nova-network
21:20:54 <russellb> bottom of that one
21:20:54 <sc68cal> mestery: I'll try and respin a new patch for the get a network spec, from everyone's comments
21:20:55 <ajo> thanks :)
21:21:03 <mestery> sc68cal: Taht would be perfect, thank you so much!
21:21:04 <sc68cal> and recollections
21:21:20 <markmcclain> mestery: I know a few of us have kicked around some of the impl details for get me a network
21:21:22 <mestery> sc68cal: That one is important an would be great to get it rolling and into shape
21:21:27 <mestery> markmcclain: ++, awesome!
21:21:32 <markmcclain> conceptually it's simple.. except for the concurrency part
21:21:39 <sc68cal> mestery: understood, however we did prioritize, linux bridge has higher priority
21:21:40 <mestery> If possible. that's a prime candidate to make fast progress on during the mid-cycle in Fort Collins
21:21:44 <mestery> markmcclain: Agreed
21:21:47 <markmcclain> mestery: ++
21:22:13 <anteaya> so the hope is to have the spec approved by fort collins?
21:22:24 <mestery> anteaya: Yup, and code in flight too!
21:22:32 <mestery> Also, markmcclain, I saw one AI for you from last week too:
21:22:34 <anteaya> okay thank you
21:22:35 <mestery> "markmcclain to write a devref document about ebtables code in support of source mac filtering and DVR/LB work"
21:22:37 <salv-orlando_> Ah the expectations...
21:22:44 <anteaya> salv-orlando_: shhhh
21:24:07 <markmcclain> mestery: yes ran a bit behind... hope to post it tomorrow
21:24:14 <mestery> Anyways, looking forward to seeing this progress on the critical nova-network/neutron compatibility tasks!
21:24:27 <mestery> markmcclain: No worries, I was just looking through AIs because I knew I had 2. :)
21:24:41 <kevinbenton> what is an AI?
21:24:44 <russellb> action item
21:24:45 <sc68cal> If someone wants to take over the get me a network spec, that'd be fine too
21:24:46 <mestery> Action Item
21:24:48 <mestery> :)
21:25:00 <sc68cal> I'm not seeing good progress on the linux bridge side yet, so maybe time to parallelize since I don't scale
21:25:04 <russellb> kevinbenton: you generally don't want them :)
21:25:09 <mestery> lol
21:25:20 <mestery> sc68cal: How goes the Linuxbridge front BTW? Are you stalled somewhere?
21:25:22 <anteaya> sc68cal: what is stcuk?
21:25:25 <anteaya> stuck
21:25:49 <kevinbenton> markmcclain: i will write the ebtables arp spoofing filter code
21:25:54 <armax> sc68cal: I would be happy to look into it, were you going to work on it?
21:25:56 <sc68cal> There's a lot of restructuring that needs to happen in DevStack, basically lib/neutron always assumes you're using OVS, and the code reflects that
21:26:18 <anteaya> sc68cal: do you have a patch set that reflects current status?
21:26:25 <sc68cal> I'm going to send an e-mail to see if anyone has ever used Linux Bridge with DevStack
21:26:30 <anteaya> or etherpad that summarizes your thoughts?
21:26:46 <sc68cal> anteaya: no, I plan on a ML post this week
21:26:47 <mestery> sc68cal: I've used it! I have a cloud VM running it at the moment in fact
21:26:52 <ajo> sc68cal, I haven't I'd like to know how to do it ;)
21:26:55 <mestery> sc68cal: At least for some tesitng purposes
21:27:01 <sc68cal> mestery: ok, share your local.conf plz
21:27:03 <ajo> mestery: show us the way! ;)
21:27:06 <armax> sc68cal: I suspect that the latest changes to devstack broke LB completely
21:27:11 <mestery> sc68cal: Will do /cc ajo
21:27:20 <anteaya> sc68cal: can I suggest an etherpad as well to keep notes to others can see what they can do to help?
21:27:26 <sc68cal> anteaya: sure.
21:27:30 <anteaya> ml's threads are tough to keep track of
21:27:40 <anteaya> great for input and ideas but tough to summarize
21:27:42 <haleyb> sc68cal: i can help too
21:28:04 <anteaya> sc68cal: I can help you put that together
21:28:30 <sc68cal> ok - i'll ping people tomorrow - let this meeting end quickly like mestery wants
21:28:38 <anteaya> k
21:28:39 <mestery> lol
21:28:40 <mestery> No worries on quick meeting end
21:29:09 <mestery> sc68cal: Did you see volunteers on "Get Me a Network" above? /cc armax haleyb
21:29:34 * haleyb hopes his memory of that meeting was accurate
21:29:43 <sc68cal> mestery: yep, that sounds good to me, I know haleyb put a couple comments in about what he remembered, I was just going to transcribe :)
21:29:52 <sc68cal> so if they want to take it, please do
21:30:05 <mestery> cool
21:30:37 <mestery> #topic Open Discussion
21:30:46 <wwriverrat> nOOb question alert: What are my next steps for review of neutron spec targeting liberty: https://review.openstack.org/#/c/180803
21:31:23 <wwriverrat> seems like discussion has ebbed off. I’d be glad to put together a schedule of work.
21:31:52 <Sukhdev> I have a question on the decamp part II
21:31:55 <mestery> wwriverrat: I'd like salv-orlando_ to meander in and look at your spec given the comment about it relating to the quota work he's doing
21:32:08 <wwriverrat> makes sense
21:32:32 <mestery> wwriverrat: Thanks!
21:32:50 <mestery> Sukhdev: Please, ask away!
21:33:14 <Sukhdev> I saw the patch by HenryG - this is good stuff - but, I have generic question -
21:33:27 <HenryG> mestery: wwriverrat: yes, salv-orlando should look at it, and we should also get someone from the api-wg to glance at the proposed api
21:33:58 <Sukhdev> Now that 80% stuff is already out of the tree - there really should not be rush to pull everything out - why not make it voluntary as opposed to mandatory?
21:34:00 <wwriverrat> makes sense. How do we poke the api-wg group for a looksee
21:34:03 <armax> Sukhdev: you’re only gonna get a generic response
21:34:04 <armax> :)
21:34:13 <Sukhdev> armax: ha ha
21:34:13 <HenryG> wwriverrat: I'll do it
21:34:17 <mestery> HenryG: Thanks!
21:34:21 <russellb> IMO, I think having stuff split in half is gross :)
21:34:43 <armax> Sukhdev: there’s stuff that hasn’t decomposed at all yet
21:34:48 <dougwig> Sukhdev: is the concern technical or marketing in nature?
21:34:56 <armax> but +1 to what russellb said
21:35:11 <dougwig> (both would be valid.)
21:35:17 <Sukhdev> dougwig: basically unnecessary additional work - which does not need to exist -
21:35:19 <russellb> hopefully still officially recognizing things as part of "Neutron" helps the marketing side though
21:35:23 <armax> the problem is not so much to what we got so far
21:35:26 <mestery> russellb: ++
21:35:33 <Sukhdev> since heavy lifting has already happened
21:35:34 <armax> but to what may potentially come in the future
21:35:40 <mestery> I think the bigger issue is those who haven't started at all.
21:35:42 <dougwig> russellb: good point
21:35:47 <armax> we’d want to have a single way we tell people how to develop stuff against the tree
21:36:06 <wwriverrat> Last question: I assume you’d want the schedule of work for that spec to be logged within the blueprint?
21:36:08 <Sukhdev> we should see what king of impact (in terms of load) did decamp phase 1 did and then evaluate if phase 2 makes sense
21:36:17 <anteaya> you need to reward folks who do as you request, not reward them for dragging their feet
21:36:23 <russellb> i think phase 2 makes a lot of sense from a technical perspective though
21:36:35 <armax> Sukhdev: I’d argue that if one has already decomposed, going all the way requires only a minimal extra effort
21:36:35 <russellb> like ... just a pure code sanity thing of how things are organized
21:36:37 <kevinbenton> while we still have drivers in, everyone that is out gets flak from their marketing department to get things in. if we have everyone out, then there is no diff
21:36:43 <Sukhdev> anteaya: this is not about rewards
21:36:51 <armax> Sukhdev: but I agree that it can depend on the level of integration achieved so far
21:36:53 <mestery> wwriverrat: To the best of your efforts, yes. Thhough realistically, it just has to land before Liberty closes
21:37:06 <anteaya> Sukhdev: it is about sending a clear message to folks about behavioural expectations
21:37:08 <wwriverrat> cool. thx!
21:37:37 <Sukhdev> armax: I think instead of mandating phase 2, it should be volunteer - as there is a value for vendors to do phase 2
21:37:39 <mestery> Did I miss the part where we decided not to eventually remove those plugins/drivers that don't comply with decomp?
21:37:47 <mestery> Because that's the stick if people don't take the carrot, so to speak.
21:38:19 <Sukhdev> anteaya: Phase 1 had clear reasons - it was choking the cores and it was holding up the vendors -
21:38:34 <Sukhdev> anteaya: that issue has been solved - now it is gravy :-)
21:38:35 <russellb> phase 2 == finishing up phase 1 IMO
21:38:40 <russellb> i don't think it can stop where it is
21:38:47 <mestery> Agreed
21:38:47 <russellb> i really think it's important and valuable
21:38:48 <anteaya> Sukhdev: I'm unclear on your definition of phase 1 and phase 2
21:38:52 <dougwig> russellb: +1
21:38:59 <anteaya> Sukhdev: to me it is people who listen and people who don't
21:39:03 <mestery> Can someone link HenryG's patch here for the record?
21:39:08 <anteaya> and I favour people who listen, heavily
21:39:13 <Sukhdev> anteaya:-)
21:39:22 <armax> #link https://review.openstack.org/#/c/187267/
21:39:50 <mestery> thanks armax
21:40:10 <Sukhdev> BTW, I am not against phase 2, please do not take me wrong - but, thought it should be volunteer basis
21:40:13 <armax> Sukhdev: the long term goal for the decomp was all to take everything out
21:40:21 <armax> Sukhdev: backing out now is non-sensical
21:40:22 <HenryG> An update to that patch is due shortly, with a lot more info
21:40:31 <Sukhdev> unless you guys have a data to say that what we have is broken
21:40:52 <russellb> it's just incomplete
21:40:55 <armax> Sukhdev: it’s not that it’s broken, it’s not the end goal we set for ourselves
21:41:00 <mestery> Right
21:41:04 <mestery> The end goal was everything decomposed
21:41:12 <armax> Sukhdev: surely we can always reassess over time
21:41:21 <Sukhdev> mestery armax: OK - understood
21:41:25 <armax> Sukhdev: but I don’t think we have enough ground to justify stopping halfway
21:41:31 <mestery> armax: ++
21:41:37 <rkukura> Actually, once we move the drivers to different repos, we can re-compose them ;)
21:41:40 <salv-mobile> I think what armax says was the plan in the first place
21:41:50 <HenryG> Even the "small" patches from vendors for their remaining in-tree code is drag on the core reviewing
21:42:13 <dougwig> Sukhdev: do you really think the end goal is to have migrations and models in one-tree, and plugins in another?
21:42:23 <dougwig> and i don't know why i hyphenated that.
21:42:25 <salv-mobile> There is no reason for leaving anything in tree, now that also the db migrations have a viable solution
21:42:27 <Sukhdev> armax mestery: I am in agreement with you - please do not take me wrong - just want to make sure we are not doing work for the sake of doing work :-)
21:42:47 <mestery> Sukhdev: When has that ever stopped anyone? :)
21:42:52 <mestery> But seriously
21:42:52 <armax> Sukhdev: true, and I appreciate the question, it’s not a generic question at all :)
21:42:56 <mestery> We can't leave it half-baked like it is now
21:43:07 <salv-mobile> sukhdev... Those who work for the sake of work never waste their time
21:43:19 <armax> Sukhdev: I think it’s important to reassess regularly objectives in light of latest events
21:43:20 <Sukhdev> salv-mobile: :-)
21:43:21 <ajo> :-)
21:43:52 <Sukhdev> Cool - I just wanted to raise everybody's attention - thanks for listening
21:44:04 <armax> Sukhdev: but I believe that consistency is worth the extra step
21:44:28 <Sukhdev> Looks like we have a consensus
21:44:34 <dougwig> the yak is baby smooth.
21:44:45 <ajo> stick ready.. ;)
21:44:47 <mestery> and green!
21:44:49 <markmcclain> dougwig: I don't like the color
21:45:04 <armax> and as mentioned the past cycle, we won’t threaten of removal if  if people don’t comply with the ‘law'
21:45:10 <mestery> OK, I think we've reached the end ... of the meeting
21:45:27 <mestery> Thanks for joinig this week!
21:45:34 * dougwig waves
21:45:36 <Sukhdev> thanks
21:45:37 <mestery> We'll see you all on the ML and IRC!
21:45:39 <mestery> #endmeeting