22:00:42 <armax> #startmeeting neutron_drivers
22:00:43 <openstack> Meeting started Thu Jun 30 22:00:42 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:43 <amotoki> hi
22:00:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:46 <openstack> The meeting name has been set to 'neutron_drivers'
22:00:54 <armax> let see if I remember how to run an irc meeting
22:01:00 <ajo> :)
22:01:01 <carl_baldwin> o/
22:01:02 <armax> bear with me if I fail
22:01:21 <armax> the usual landing page:
22:01:23 <armax> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
22:01:48 <kevinbenton> Hi
22:01:49 <dougwig> o/
22:01:51 <armax> I spent this morning going over the outstanding RFEs
22:02:04 <armax> I encourage everyone to do the same
22:02:12 <armax> but we should not neglect the outstanding specs
22:02:34 <dougwig> i found a hole in our rfe query last week.  if anyone submits code before we talk about an rfe, it jumps to 'in progress'.
22:02:44 <dougwig> and then we never talk about it.
22:02:52 <armax> dougwig: I clean that up regularly
22:02:57 <dougwig> ok
22:03:14 <armax> but yes, that’s potentially a loophole
22:03:15 <dougwig> such mad launchpad skills, i fear for your sanity
22:03:17 <carl_baldwin> We should encourage them not to use "closes-bug" but to use "related-bug" I think.
22:03:32 <armax> carl_baldwin: that falls on deaf ears
22:03:42 <armax> I don’t know how many times I said people not to create blueprints
22:03:48 <armax> they still do
22:03:49 <carl_baldwin> But, if it is documented, at least we tried.
22:03:55 <carl_baldwin> Is it documented?
22:03:56 <dougwig> just searching on tag rfe and not tag rfe-approved will find them
22:04:01 <armax> anyhoo
22:04:08 <armax> an administration info
22:04:14 <armax> I created a new tag
22:04:16 <armax> rfe-postponed
22:04:20 <ihrachys> armax: bugs are bad because the bot reassigns them on every patch upload. it sucks.
22:04:51 <amuller> ihrachys: We're not supposed to use the bug after it's approved
22:04:54 <amuller> that's what blueprints are for
22:04:56 <ajo> ihrachys, armax may be we can tweak the bot to not touch the #rfe's
22:05:23 <armax> the careful reviewer can easily spot the loophole
22:05:39 <ihrachys> amuller: then why is it suggested above we should not have bps? or I miss smth?
22:05:42 <kevinbenton> But what about us reckless reviewers?
22:05:46 <armax> when I review I go back to the bug report and if that belongs to an unpproved rfe you can always slap the contributor on the wrist
22:06:05 <armax> kevinbenton: the reckless reviewer should be stripped down of his/her +2 rights
22:06:10 <ajo> :)
22:06:12 <armax> guys
22:06:14 <armax> let’s not derail
22:06:22 <armax> unless you want to :)
22:06:27 <armax> I was saying…
22:06:44 <armax> I created an rfe-postponed tag to mark any RFE that is not quite ready to be taken on
22:07:08 <carl_baldwin> I think I could go apply that to a bunch of the bgp ones in confirmed.
22:07:13 <armax> things that we may want to consider in the future and that may require other stuff to land first
22:07:20 <mickeys> Wondering why 1509431 was moved to rfe-postponed (along with all of the BGP RFEs). There is a spec out that is being actively reviewed: https://review.openstack.org/#/c/322654/
22:07:24 <armax> carl_baldwin: I already did
22:07:32 <HenryG> So it's different from "rfe-approved + postponed"?
22:07:34 <carl_baldwin> Oh good.
22:07:52 <armax> mickeys: no-one should be stopped from reviewing
22:07:55 <ajo> and may be the qos-bandwidth-guarantee "strict" that requires the nova scheduling bits...
22:08:06 <armax> I was under the impression that the BGP team was busy putting the repo in the right shape
22:08:28 <armax> if carl_baldwin or rtidwell want to take that on for Newton I am happy to change the tag
22:08:46 <armax> ajo: go for it
22:08:54 <mickeys> armax: Thanks, will check with rtidwell
22:08:57 <amotoki> "rfe-approved + postponed" sounds odd. I think 'rfe-postponed' tag is used for potential features.
22:08:59 <ajo> postponed!
22:09:01 <ajo> :)
22:09:28 <armax> mickeys: sure, and sorry I didn’t mean to give you a scare
22:09:31 <mlavalle> mickeys: his irc nic tidwellr
22:09:39 <armax> mlavalle: thanks
22:09:49 <armax> I don’t see him online
22:09:57 <armax> ok, we good? shall we proceed?
22:10:00 <mlavalle> armax: he is in the Neutron channel
22:10:06 <armax> mlavalle: ack
22:10:16 <armax> another thing...
22:10:19 <armax> did you guys miss me?
22:10:20 <armax> :)
22:10:27 <mlavalle> deeply
22:10:31 <ajo> armax, of course we did
22:10:32 <HenryG> No, because you were never gone
22:10:35 <ihrachys> nope. you bugged me every single day.
22:10:36 <ajo> lol
22:10:41 <armax> oh come on
22:10:50 <ajo> armax, did you miss us? :P
22:11:08 <ajo> or did we also bugged you every single day? :)
22:11:09 <armax> did I?
22:11:10 <armax> :)
22:11:31 <armax> I think it’s good to be back
22:11:44 <armax> let’s proceed
22:11:51 <armax> bug #1476527
22:11:51 <openstack> bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] https://launchpad.net/bugs/1476527
22:11:59 <armax> I have had a chance to review this...again
22:12:47 <armax> anyone had a chance to pay attention to this?
22:12:59 <armax> I know that sc68cal had a chat with a few folks
22:13:24 <ajo> I did too
22:13:27 <dougwig> i thought this was already in progress, in neutron-classifier
22:13:39 <ajo> on summit and a couple of meetings with them afterwards
22:13:42 <dougwig> but i haven't been following it
22:13:48 <armax> dougwig: I think there’s some lack of clarity on how this actually is supposed to work
22:13:50 <ihrachys> neutron-classifier is nothing but data models.
22:13:53 <armax> integrate with the data plane etc
22:14:08 <dougwig> ahh, the integration part.
22:14:12 <armax> ihrachys: but is it meant to stay that way?
22:14:19 <ihrachys> armax: the way I see it, TC is merely an API abstraction that can be consumed by other features
22:14:23 <ihrachys> so no data plane
22:14:26 <ajo> data models, and an API
22:14:29 <ajo> exactly
22:14:43 <armax> and any backend implements its own?
22:15:05 * armax waits for an answer
22:15:10 <ajo> a common library could be provided to transform TC's into openflow matches, or iptables matches, or X-random-tech-matches, if we want, and we find it useful
22:15:27 <dougwig> i had hoped part of the goal was unifying the many packet flow mechanisms that are sprining up in every new subproject.
22:15:33 <dougwig> springing
22:15:45 <ihrachys> armax: I don't know. I would be fine to implement a service plugin in the repo. it's others who want to colocate it. I agree though that the initiative should be tightly supervised by the neutron team.
22:16:00 <armax> ok, but that’s for whoever is meant to implement TC
22:16:07 <armax> but what about the one that is meant to use TC
22:16:10 <kevinbenton> TC?
22:16:15 <ajo> traffic classifier
22:16:16 <armax> traffic classification
22:16:21 <ihrachys> armax: we MAY also produce a lib, as ajo said; but I don't think that's the first step to take.
22:16:23 <armax> kevinbenton: coffee?
22:16:33 <ajo> take-coffee
22:17:12 <armax> ok
22:17:27 <armax> we should have this better outlined on the spec
22:17:28 * kevinbenton is having coffee now
22:17:32 <ihrachys> I would suggest we implement api layer; then once features start to use it, we'll see if there is common ground for them to reuse backend side
22:17:41 <armax> ihrachys, ajo: are you guys able to eyeball the spec?
22:17:44 <amotoki> there are several aspects which a common lib can cover: API validation, data models, data plane...
22:17:57 <ihrachys> armax: that's on my horizon, but I have only 24/7
22:18:10 <armax> ihrachys: you should live on a plane going around the world
22:18:16 <armax> westwards
22:18:20 <ihrachys> sometimes I feel like I do
22:18:21 <dougwig> lol
22:18:23 <ajo> armax, I can
22:18:31 <armax> ajo: thanks
22:18:33 <armax> let’s move on
22:18:34 <dougwig> i do often wonder when ihrachys sleeps.
22:18:43 <armax> bug #1552680
22:18:43 <openstack> bug 1552680 in neutron "[RFE] Add support for DLM" [Wishlist,Triaged] https://launchpad.net/bugs/1552680 - Assigned to John Schwarz (jschwarz)
22:18:47 <ajo> dougwig, he doesn't
22:18:59 <ajo> dougwig, just a tiny bit
22:19:02 <jschwarz> Hello
22:19:05 <armax> I did review the doc
22:19:10 <armax> jschwarz: great job
22:19:14 <jschwarz> armax: thanks
22:19:21 <armax> I was expecting to see the results broken down by tooz backend
22:19:38 <armax> jschwarz: but that’s not super important
22:19:49 <jschwarz> once I have all the results I'll produce a readable report
22:19:54 <armax> jschwarz: great
22:19:58 <jschwarz> I'm just not quite there yet
22:20:04 <dougwig> any highlights?
22:20:12 <armax> I think we collectively as a team want to decide if we want to impose an extra deployment requirement on operators
22:20:20 <amuller> I don't think it's our job to compare tooz backends
22:20:26 <amuller> imo not the best usage of our time
22:20:27 <jschwarz> so far it seems like DLMs give a higher-than-expected overhead for the trivial case, so I'm looking into that
22:20:29 <armax> because jschwarz has demonstrated that the code itself can be rather simple and the overhead marginal
22:20:40 <armax> amuller: I wasn’t suggesting that
22:20:56 <armax> the doc says that experiments were conducted for the three backends
22:21:01 <dougwig> amuller: i think we're just trying to characterize the overall hit, not care about any one backend in particular.
22:21:02 <armax> I wondered where the results were
22:21:12 <amuller> dougwig: agreed
22:21:18 <armax> but I am ok with the aggregate number if that’s what it was
22:21:41 <jschwarz> armax: I should be back from PTO early next week (Finished my last exam about 5 hours ago! :) ) and that's my first order of business
22:21:52 <jschwarz> hopefully I will have real results by next week's drivers meeting
22:22:00 <armax> jschwarz: congrats, and rest a bit
22:22:13 <jschwarz> rest is for the wicked :P
22:22:14 <armax> either way, I think the decision that lies ahead is whether we can seriously impose tooz+backend on Neutron deployments
22:22:25 <jschwarz> also, I saw armax pointing out that he's not sure if there are other core projects using tooz
22:22:33 <armax> let’s wear the distros and deployers hats for a sec
22:22:43 <armax> jschwarz: Nova is definitely not going to
22:22:45 <jschwarz> I posted back that Cinder is currently uses Tooz quite heavily in exactly the same manner we intend to
22:23:14 <jschwarz> https://github.com/openstack/cinder/blob/master/cinder/coordination.py
22:23:14 <armax> jschwarz: ok so it might be already available for deployments that do do use Cidner
22:23:20 <ihrachys> armax: distros gotta suffer :P
22:23:21 <jschwarz> exactly
22:23:29 <ajo> yeah
22:23:32 <armax> ihrachys: no come on, seriously
22:23:43 <armax> ihrachys, kevinbenton, amuller, carl_baldwin ^
22:23:46 <amuller> distros will take care of tooz and a backend anyway
22:23:52 <amuller> regardless of our choice in Neutron
22:23:56 <amuller> cause of Cinder
22:24:01 <jschwarz> is there a distro that *doesn't* use Cinder?
22:24:14 <jschwarz> if not, then what amuller said
22:24:50 <armax> ok
22:25:11 <armax> let’s gather a bit more data points on the availability of tooz in an OpenStack deployment
22:25:16 <dougwig> as long as we required all linux distros to use a windows tooz backend, we'll all get some amusement out of this.
22:25:38 <ajo> X)
22:25:39 <armax> kevinbenton: can you find out about Mirantis?
22:25:46 <armax> kevinbenton: or do you know alrady?
22:25:48 <armax> already?
22:25:59 <armax> mestery: do you roll out Cinder?
22:26:02 <jschwarz> dougwig: the only thing Microsoft know to do well with distributed, is pushing Windows 10 to everyone distributively evenly
22:26:25 <kevinbenton> i can look into it
22:26:30 <armax> kevinbenton: please
22:26:41 <armax> amuller: what about RHEL?
22:27:08 <amuller> armax: let's assume that won't be a problem
22:27:32 <ihrachys> jschwarz: wait, https://github.com/openstack/cinder/commit/d6fabaa6cf7700cfb957e37594d0da818afea806 release note suggest that tooz MAY be used
22:27:37 <armax> ok, let’s post findings on the bug report and make a decision then
22:27:51 <ihrachys> amuller: well, I've heard packaging zookeeper is a real pita
22:28:03 <amuller> ihrachys: if there's pressure from upstream we will have to find a solution either way
22:28:23 <armax> amuller: I don’t want to be the first one though :)
22:28:31 <jschwarz> ihrachys: I think it means that "you are now allowed to use tooz"
22:28:34 <armax> I’d rather have someone else take the blame
22:28:37 <ajo> ihrachys, yes, I heard that too
22:28:51 <jschwarz> ihrachys: since then the @synchronized decorator has been introduced in a lot of places around the code
22:28:53 <ajo> java fun
22:28:57 <armax> carl_baldwin or I are gonna find out about HOS
22:29:04 <ihrachys> jschwarz: ack
22:29:13 <amuller> armax: maybe tooz authors would have interesting input about its usage
22:29:16 <armax> kevinbenton: is gonna find out aboug MOS
22:29:23 <carl_baldwin> i can ask if you want
22:29:32 <armax> amuller: is going to find out about ROS?
22:29:43 <armax> how do you call yours?
22:29:45 <jschwarz> armax: RHOS
22:29:45 <amuller> RDO :)
22:29:48 <armax> right
22:29:49 <dougwig> i also don't think there's any harm in punting this, and letting tooz mature. the last thing we need is another reason for people to think neutron is buggy.
22:29:49 <armax> RDO
22:29:53 <armax> where’s my head?
22:30:11 <armax> ok moving on
22:30:22 <armax> bug #1563879
22:30:22 <openstack> bug 1563879 in neutron "[RFE] DVR should route packets to Instances behind the L2 Gateway" [Wishlist,Triaged] https://launchpad.net/bugs/1563879
22:30:58 <jschwarz> And to all, a good night. See you next week! :)
22:31:00 <armax> swami is not in channel
22:31:03 <armax> jschwarz: nite!
22:31:32 <armax> I think the l2gw repo has a fix targeted that works under certain conditions
22:31:58 <armax> but I am unclear on the scope of the work because the RFE doesn’t have a lot
22:32:26 <armax> this is probably a candidate for rfe-postponed if the DVR plate is alraedy full with fast-exit and such
22:32:32 <armax> carl_baldwin: what do you think/know?
22:33:00 <carl_baldwin> I'm not up on l2gw related stuff.
22:33:05 <armax> I mean on DVR
22:33:17 <armax> carl_baldwin: you have your plate full already don’t you?
22:33:18 <carl_baldwin> Oh, the DVR plate?
22:33:26 <carl_baldwin> Mine is pretty full.
22:33:33 * armax subtly is telling carl_baldwin to nod along
22:33:36 <carl_baldwin> But, there is a DVR team that we could ask.
22:33:46 <carl_baldwin> I think they're pretty busy too.
22:34:05 * carl_baldwin nods
22:34:12 <armax> carl_baldwin: ok, so I leave the action to you to mark it postponed once you cleared with the team?
22:34:23 <armax> carl_baldwin: the dvr team I mean?
22:34:42 <carl_baldwin> yes
22:34:46 <armax> carl_baldwin: again, there was a patch in the l2gw repo but I am unsure if that suffices to kill this RFE
22:35:20 <armax> if Swami confirms that it does, then we can move it directly to approved as the patch was rather easy to digest
22:35:23 <carl_baldwin> I'll follow up on this.
22:35:32 <armax> carl_baldwin: thank you sir
22:35:39 <armax> moving on
22:35:42 <armax> bug #1566520
22:35:42 <openstack> bug 1566520 in neutron "[RFE] Upgrade controllers with no API downtime" [Wishlist,Triaged] https://launchpad.net/bugs/1566520
22:35:53 <armax> who wants this?
22:36:01 <armax> I do
22:36:11 <dougwig> i'd want it if i was an operator.
22:36:35 <armax> anyone else?
22:36:45 <amotoki> me too. it brings us true live upgrade.
22:36:46 <carl_baldwin> Who would say they don't want it?
22:36:52 <armax> carl_baldwin: right
22:36:56 <ajo> exactly
22:36:56 <ihrachys> that, and a pony
22:36:57 <dougwig> people who hate uptime.
22:37:03 * armax subtly is telling people to say ‘I do’
22:37:04 <HenryG> developers
22:37:11 <kevinbenton> and people who care about data schemas :)
22:37:21 <carl_baldwin> We need to consider the cost though.  It is going to take some work to get there.
22:37:22 <dasm> ihrachys: is this "enhancement to ovo?
22:37:28 <dougwig> ok, so kevinbenton hates uptime and is a developer.  check.
22:37:32 <armax> carl_baldwin: yes, nothing is cheap or free
22:37:40 <ihrachys> dasm: no, ovo is means, and that's the actual goal
22:38:08 <dasm> armax: i'm not a operator, but would like to have live upgrade. I do.
22:38:24 <armax> let’s put it this way
22:38:40 <armax> we can only have tooz if we have online upgrades
22:38:46 <armax> the carrot and the stick
22:38:50 <armax> if you catch my drift
22:39:06 <kevinbenton> they both sound like sticks to me :)
22:39:06 <ihrachys> carl_baldwin: what would be the process to consider?
22:39:08 <dougwig> but i'm not dying for tooz, and i do want online upgrade.  your carrot sucks.
22:39:20 <armax> lol
22:39:38 <armax> dougwig: don’t you want a more reliable system?
22:39:45 <armax> and a more available one?
22:39:56 <ihrachys> dougwig: now, another question: would you want online upgrades IN OCTAVIA? :)
22:40:08 <dougwig> ihrachys: indeed, i do.
22:40:17 <dougwig> armax: DLM is not the only path to being more reliable.
22:40:18 <ihrachys> ok test passed
22:40:30 <armax> dougwig: right, more code complexity is
22:40:45 <armax> tooz may make the code simpler but operations harder
22:40:57 <armax> online upgrades are the opposite: make the code more complex but the operation simpler
22:41:59 <ajo> you want a pony ? , ok, you'll have to take care of it ;)
22:42:15 <armax> anyway we’re digressing…in general we should encourage ways to improve the availability of Neutron as a system the same way we want to encourage ways to improve reliability
22:42:19 <dougwig> ajo: this is cloud software; pets get shot
22:42:21 <armax> the trick is in the price to pay and who pays it
22:42:31 <ajo> dougwig, crap XD
22:43:12 <armax> the pain points of the user should be given priority compared to the pain points of the developer
22:43:34 <ajo> unless you kill the developer
22:43:41 <armax> ajo: of course
22:43:44 <amuller> unless your software is so complex no one wants to work on it
22:43:44 <ajo> but that's ok if developers are pets
22:43:50 <ihrachys> does anyone want a detailed analysis of the cost in that particular case?
22:43:52 <amuller> it's a balance like everything :)
22:44:02 <dougwig> sigh, openstack users ARE developers at this point.
22:44:14 <armax> I think that other projects have proven that online upgrades are doable
22:44:18 <armax> we’re not trail blazers here
22:44:22 <dougwig> ihrachys: if you've got it, yes
22:44:33 <ihrachys> dougwig: I can produce it. not today, but generally.
22:44:53 <armax> ok, I guess we’re inclined to approve this rfe
22:44:55 <ihrachys> dougwig: I think I feel some lack of understanding of the plan to get to the pony
22:44:56 <armax> any veto?
22:45:06 <ihrachys> so maybe writing up is good anyhow
22:45:40 <armax> none
22:45:54 <dougwig> no vote, i'm all in favor.
22:45:57 <dougwig> no veto
22:46:00 <dougwig> same letters.
22:46:05 <carl_baldwin> I'm in favor
22:46:20 <HenryG> me2
22:46:21 <amotoki> none
22:46:35 <armax> we need to figure out the order certain efforts need to happen
22:46:48 <armax> like the keystone v3 migraiton
22:46:48 <kevinbenton> easy, stop all development :)
22:46:52 <ihrachys> note it will span into Ocata
22:47:02 <dougwig> i expect it to span into Q.
22:47:11 <armax> I expect to span into A
22:47:37 <dougwig> i think armax just segfaulted (array bounds)
22:48:01 <ihrachys> armax: I think we are settled that contract branch will live for at least till Newton final, keystone v3 is in good shape to happen before Ocata.
22:48:11 <armax> ihrachys: ack
22:48:26 <armax> so long as we have full awareness of the other things in flight
22:48:46 <armax> then we should be good
22:49:07 <armax> movign on
22:49:15 <armax> bug #1580880
22:49:15 <openstack> bug 1580880 in neutron "[RFE] Distributed Portbinding for all port types" [Wishlist,Triaged] https://launchpad.net/bugs/1580880 - Assigned to Andreas Scheuring (andreas-scheuring)
22:49:25 <armax> I have failed to review this ahead of the meeting
22:49:33 <armax> it’s next on my stack though
22:49:36 <carl_baldwin> This is a Nova/Neutron cross project thing.
22:49:44 <armax> ok
22:49:48 <carl_baldwin> The pain is felt when doing live migration.
22:50:10 <carl_baldwin> I've been trying to feel out the Nova side to see how they want to prioritize their part.
22:50:18 <dougwig> service VMs are another big use case here.
22:50:33 <carl_baldwin> It is on the agenda for the mid-cycle in Portland.
22:50:41 <armax> carl_baldwin: it looks like one of the live migraiton patches that targeted Nova has yet to be merged
22:50:53 <armax> like this oen?
22:50:54 <armax> https://review.openstack.org/#/c/275073/
22:51:30 <armax> or like https://review.openstack.org/#/c/246910/
22:52:35 <carl_baldwin> So, this would be a whole 'nother live migration related change in Nova.
22:52:46 <armax> ok
22:52:46 <carl_baldwin> armax: You thinking they're not giving these much attention or priority?
22:53:01 <armax> I thought that live migration was a priority for Mitaka
22:53:27 <armax> but there’s probably enough to make those deferred
22:53:35 <dasm> armax: it was. but because for mitaka it was priority, for newton they don't think so that it's important.
22:54:08 <dasm> so live migration (not everything finished) was degraded for newton
22:54:09 <armax> there are certain tasks that I’d rather align with Nova
22:54:19 <armax> in terms of priority
22:54:43 <armax> otherwise it feels like we’d do work we’d never know we’d be able to leverage from their side
22:55:09 <carl_baldwin> My thoughts exactly.  That's why I was trying to feel it out a bit.
22:55:23 <mlavalle> lol
22:55:24 <armax> carl_baldwin: ok, let’s continue to gauge their interest
22:55:28 <armax> bug #1583694
22:55:28 <openstack> bug 1583694 in neutron "[RFE] DVR support for Allowed_address_pair port that are bound to multiple ACTIVE VM ports" [Wishlist,Triaged] https://launchpad.net/bugs/1583694 - Assigned to Swaminathan Vasudevan (swaminathan-vasudevan)
22:55:43 <carl_baldwin> armax: Let's bring it up at their mid-cycle when we're all there.
22:55:57 <armax> I was asking for an update on this one, I looked at the patches but that didn’t click for me
22:56:04 <armax> anyone has anything to add?
22:56:30 <armax> no?
22:56:30 <armax> ok
22:56:35 <armax> bug #1592918
22:56:35 <openstack> bug 1592918 in neutron "[RFE] Adding Port Statistics to Neutron Metering Agent" [Wishlist,Triaged] https://launchpad.net/bugs/1592918 - Assigned to Sana Khan (sana.khan)
22:56:46 <carl_baldwin> armax: Sorry, no.  Nothing to add.
22:57:01 <armax> this seems pretty straightforward, rossella_s said she’s happy to help
22:57:49 <armax> it does seem that the data being captured here would be the same that is available through ‘nova diagnostics'
22:58:07 <dougwig> i see OVS mentioned.  what about LB?
22:58:13 <armax> but if we allowed this we could capture this data for all ports, not just computes
22:59:06 <armax> I suppose the submitter is interesed in OVS only
22:59:29 <armax> but we can see if LB can be enough of a low hanging fruit
22:59:36 <amotoki> it is straightforward. question is where we implement it. l2-agent or metering-agent?
22:59:44 <amotoki> i am not sure which is simpler.
23:00:11 <carl_baldwin> Just hit time
23:00:13 <armax> amotoki: right now it looks like it’s targeting the metering agent
23:00:16 <armax> ok folks
23:00:28 <amotoki> armax: yeah. the rfe says so.
23:00:34 <armax> thanks for joining, please take the time to review the specs of the approved RFEs
23:00:41 <armax> bye!
23:00:41 <ajo> metering agent seems reasonable
23:00:46 <armax> #endmeeting