22:14:58 <armax> #startmeeting neutron_drivers
22:14:59 <openstack> Meeting started Thu Aug 11 22:14:58 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:15:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:15:02 <openstack> The meeting name has been set to 'neutron_drivers'
22:15:13 <njohnsto_> \o/
22:17:55 <armax> HenryG, kevinbenton: so where do we go from here
22:17:55 <armax> ?
22:18:30 <kevinbenton> HenryG, armax: I think it will get done a lot quicker if we use the context managers
22:18:46 <HenryG> I hope so, let's try that
22:18:47 <kevinbenton> using the decorators means the whole function has to be 'PRECOMMIT' so-to-speak
22:18:51 <armax> kevinbenton: it depends if that’s what zzzeek was proposing?
22:18:56 <kevinbenton> which means every one requires a refactor
22:19:24 <kevinbenton> armax: well the difference between the context manager and the decorator is just syntax
22:19:27 <armax> kevinbenton: yes, that’s something I questioned
22:19:33 <kevinbenton> they both use the new reader/writer thingy
22:19:44 <kevinbenton> so we still get the advantages of that
22:20:14 <HenryG> I don't know if zzzeek new how many of our methods do things after commiting before they return
22:20:21 <HenryG> *knew
22:20:35 <kevinbenton> yeah, or did things before teh transaction started
22:20:41 <HenryG> right
22:20:55 <armax> HenryG: I suppose this was investigation required before starting this endeavor
22:21:35 <kevinbenton> but really the difference between the decorator vs the context manager is just syntactic sugar
22:21:44 <HenryG> armax: Yeah, my bad
22:21:47 <kevinbenton> the important thing is switching to the new facade
22:22:13 <HenryG> I'll also check with Ann how much time she has to work on the BP. We may need to assign additional people.
22:22:25 <armax> I see two chunks of work here
22:22:40 <armax> switching to the facade, and revising the DB interactions throught the codebase, if required
22:22:45 <armax> have we done the former?
22:22:49 <HenryG> yes
22:22:58 <armax> ok, great
22:23:05 <armax> no though we must leverage it
22:23:09 <armax> fully
22:23:10 <armax> correct?
22:23:13 <HenryG> right
22:23:16 <armax> sweet
22:23:42 <armax> as for the way we leverage it we can either go with what kevinbenton is suggesting
22:23:43 <HenryG> There was a bump due to incorporating osprofiler
22:23:45 <armax> which seems less invasive
22:24:02 <armax> or go with what zzeeek was suggesting, which is more invasive?
22:24:40 <HenryG> it requires refactoring, yes
22:24:45 <armax> can we come up with a plan in time for the mid-cycle so that we can pull this off by the end of next week? Is it achievable?
22:24:48 <kevinbenton> there is almost no benefit to using the decorator instead of the manager. the only thing i can see is that it makes it a little easier to reason about a function being entirely enclosed in a transaction
22:25:26 <kevinbenton> so even if we could do the decorator really quickly, i would be against it this late in the cycle due to all of the code churn it will cause
22:25:54 <HenryG> the "plan" would be 'search and replace' using the context manager
22:25:59 <armax> kevinbenton: we can’t simply apply the decorator blindly though, can we?
22:26:00 <kevinbenton> HenryG: +1
22:26:06 <kevinbenton> armax: that's my point
22:26:16 <kevinbenton> armax: decorator we can't apply without thinking and refactoring
22:26:21 <armax> kevinbenton: right, that goes back to the refactoring need, which is a mess
22:26:23 <kevinbenton> armax: context manager we pretty much can
22:26:28 <armax> ack
22:26:42 <armax> do we lose any benefit if we used the context manager based approver over decorators?
22:26:52 <armax> then we can still make a mandate that new junk uses the decorator
22:26:57 <armax> can the two co-exist?
22:27:02 <kevinbenton> no different
22:27:11 <kevinbenton> they are just different entry points into the same class
22:27:14 <kevinbenton> i looked into it
22:27:16 <HenryG> Using the decorator forces a cleaner transaction design IMO
22:27:37 <armax> right, so if it’s cleaner/more readable to use the decorator then we can suggest using it during code review
22:27:45 <armax> and apply it where it’s easier to do so
22:27:51 <amuller> agreed
22:27:56 <amuller> it's two different efforts
22:28:04 <armax> ie. the whole method is easily wrappable
22:28:33 <kevinbenton> that becomes difficult when we want to emit PRECOMMIT and AFTER events
22:28:47 <armax> kevinbenton: understood
22:28:48 <kevinbenton> just have to break things down into more functions i suppose
22:28:54 <armax> correct
22:29:02 <HenryG> ack
22:29:05 <armax> we can apply this ad hoc
22:29:23 <armax> and going forward we can keep an eye on suggesting to use the decorator-based approach where it makes sense
22:29:41 <armax> for now, we should switch to the new facade everywhere where it’s needed
22:29:43 <armax> and be done with it
22:29:52 <HenryG> I think we agree
22:29:57 <armax> going forward we can go piecemeal
22:30:17 <armax> between a little review attention and janitorial duties in cleaning up the code slowly
22:30:25 <armax> as low-hanging-fruit type of an effort
22:30:32 <armax> aye aye?
22:30:39 <HenryG> yes sir!
22:31:08 <carl_baldwin> ++
22:31:18 <armax> HenryG: please capture this on the blueprint/bug, I am going to have you take a written test next week
22:31:29 <armax> see if you can get an A
22:31:34 <armax> :)
22:31:37 <HenryG> :)
22:31:58 <armax> ok, let’s continue drilling/interrogating HenryG
22:32:14 <armax> blueprint keystone-v3
22:32:51 <armax> where’s our API compat layer shim patch?
22:32:55 <armax> show me the money!
22:33:27 <HenryG> We have tenant_id rename cleanups to do, and API update.
22:33:47 <HenryG> I have started on the former, and dasm is preparing the latter.
22:34:25 <HenryG> dasm: any update on the progress?
22:34:43 <dasm> i talked to blogan about ideas how to implement api change.
22:35:02 <dasm> although it's not baked yet
22:35:13 <armax> ok
22:35:30 <dasm> i have couple ideas and will prepare it asap
22:35:41 <armax> dasm: ack
22:35:48 <armax> can you give us an ETA?
22:36:12 <armax> is it something we can look at next week you reckon?
22:36:20 <dasm> i hope
22:36:44 <dasm> will try to do this till EOD Tuesday
22:37:09 <armax> dasm: ok, if there’s anything we can do, a shoulder to cry on…or anything else give us a shout
22:37:15 <armax> :)
22:37:26 <dasm> armax: shoulder is nice :) will remember, thanks
22:37:38 <armax> dasm: I can bring candies too
22:37:45 <armax> dasm: sugar helps
22:38:00 <dasm> :) let's leave it for midcycle
22:38:06 <armax> deal
22:38:11 <HenryG> dasm: whatever you have, we can accelerate on it in person in Cork
22:38:24 <kevinbenton> linux bridge job is busted!?!? stop the press!
22:38:38 <HenryG> kevinbenton: fix is in the works
22:38:49 <armax> kevinbenton: YES
22:38:57 <armax> it’s a nova issue
22:39:08 <HenryG> os-vif actually
22:39:20 <armax> https://review.openstack.org/#/c/354402/
22:39:28 <kevinbenton> sorry for meeting hijack :)
22:39:29 <armax> https://review.openstack.org/#/c/354143/
22:39:35 <armax> HenryG: you stand corrected :)
22:39:56 <armax> but yeah I can lean towards your statement ;)
22:40:06 <armax> ok let’s move on
22:40:33 <armax> HenryG: you can relax now
22:40:53 <HenryG> I was never unrelaxed :)
22:41:18 <armax> I thought my inquisitive tone was scary
22:41:22 <armax> I should practice more
22:41:38 <kevinbenton> (so we're waiting on os-vif release?)
22:42:08 <armax> kevinbenton: stop!
22:42:16 <armax> kevinbenton: actually I summon you now
22:42:21 <armax> blueprint push-notifications
22:42:56 <kevinbenton> ihar and the ovo folks are trying to get the bare minimum objects required for this work so i can at least send OVO's over the wire
22:43:08 <armax> ihar mentioned some ovo patches in preparation of some RPC work required
22:43:32 <kevinbenton> gonna sync up with him at the midcycle to make sure i have everything i need
22:43:35 <armax> you mean ports, networks, and the likes?
22:43:39 <kevinbenton> yep
22:43:55 <armax> without that you’re dead in the water?
22:44:17 <armax> how far off are we?
22:44:18 <kevinbenton> well either that or we have to send unversioned dicts over the wire
22:44:28 <kevinbenton> and figure out a backward compatibility plan
22:44:41 <kevinbenton> which may be, send the API representation
22:44:50 <kevinbenton> but that's plan B
22:44:53 <armax> ok
22:45:02 <amuller> sounds like the plan going forward will be finalized in the mid cycle anyway
22:45:05 <kevinbenton> yep
22:45:06 <armax> how close are get you unblocked?
22:45:16 <kevinbenton> need to review the latest stuff before i can tell
22:45:21 <armax> ok
22:45:36 <armax> kevinbenton: can I kindly and humbly ask you to update the whiteboard when you do?
22:45:49 <kevinbenton> armax: sure
22:45:56 <kevinbenton> armax: you can certainly ask
22:46:01 <armax> that doesn’t sound convincing
22:46:05 <armax> um
22:46:28 <armax> kevinbenton: you also promised me something to review as far as l3-flavors goes
22:46:58 <armax> kevinbenton: because of you I am spending most of my days looking at en empty gerrit queue, I have nothing to review!
22:47:17 <kevinbenton> armax: it's because i spend so much time re-reviewing these vlan-aware-vm patches from you :)
22:47:42 <armax> kevinbenton: cheap shot
22:47:59 <armax> kevinbenton: truth is, you spend too much time fixing the bugs you introduce with your bug fixes
22:48:05 <armax> kevinbenton: there!
22:48:08 <armax> top that!
22:48:12 <kevinbenton> *shots fired*
22:48:16 <armax> :)
22:48:28 <kevinbenton> where is dougwig?
22:48:38 <carl_baldwin> Getting hot on here.
22:48:42 <armax> he’s on PTO somewhere in the world
22:49:28 <armax> kevinbenton: ok, I’ll harass you offline
22:49:29 <kevinbenton> armax: i have no l3-flavors for you today
22:49:47 <kevinbenton> armax: i stepped on a landmine in the quota code that salv left for us :)
22:49:49 <johnsom> He is in glacier park...
22:50:06 <kevinbenton> i'll be in glacier the week after the mid-cycle!
22:50:10 <kevinbenton> we should have coordinated
22:50:33 <armax> kevinbenton: ok, let me understand the blast radius and we’ll come up with a remedy plan
22:51:02 <kevinbenton> armax: only a very unlikely unit test failure. nothing bad
22:51:28 <armax> kevinbenton: when do you learn that my heart is weak and you should measure the words you use?
22:51:48 <kevinbenton> armax: i didn't say it was the hindenburg!
22:52:06 <kevinbenton> armax: next topic! derailed
22:52:12 <armax> ok
22:52:18 <armax> amuller: you’re summoned
22:52:34 <armax> blueprint troubleshooting
22:52:43 <amuller> I talked to Hynek today
22:52:45 <armax> I owe you an answer on the spec, I’ll get it to you
22:52:54 <amuller> there's some sticking points on the spec he didn't really know how to answer
22:53:15 <amuller> I think some of the discussions there are kind of abstract, so I suggested he will retort with concrete examples so the discussion can be more fruitful
22:53:21 <armax> do you have time tomorrow to go over them together?
22:53:35 <amuller> yes
22:53:45 <armax> amuller: I appreciate this is a tough nut to crack
22:53:53 <amuller> yeah it's surprisingly complicated
22:54:02 <amuller> I'd appreciate it if other folks could chime in on the spec also
22:54:14 <amuller> it's largely been the Armando show
22:54:30 <carl_baldwin> I can read it tonight.
22:54:50 <amuller> #link https://review.openstack.org/#/c/308973/
22:54:56 <armax> my general concern is that the level of sophistication he’s aiming for is too high
22:54:56 <amuller> Did I do it wrong? :)
22:55:06 <armax> amuller: you did splendily
22:55:10 <armax> splendidly
22:56:23 <armax> ok, amuller hit me tomorrow
22:56:27 <amuller> armax: ack
22:56:28 <armax> figuratively speaking
22:56:53 <amuller> heeh
22:57:01 <armax> ok, let’s get 4 minutes back
22:57:04 <armax> 3 now
22:57:14 <carl_baldwin> Bye
22:57:32 <armax> thanks everyone who helped us painting a fresh picture of how messy our sausage making process is
22:57:38 <armax> #endmeeting