17:30:26 <dougwig> #startmeeting networking_lib
17:30:27 <openstack> Meeting started Wed Feb 10 17:30:26 2016 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:27 <dougwig> o/
17:30:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:30:31 <openstack> The meeting name has been set to 'networking_lib'
17:30:57 <HenryG> o/
17:31:14 <dougwig> #topic Current Work Items
17:31:28 <dougwig> Using the lib in neutron - #link https://review.openstack.org/#/c/268232/
17:31:54 <dougwig> this looks about to merge, then we'll need to start undoing deprecation warnings. i'll churn through it in batches in openstack/neutron, unless someone else wants to take a crack.
17:32:11 <dougwig> Moving base db gunk - #link https://review.openstack.org/#/c/267214/
17:32:29 <dougwig> that one is pretty core to the goal of separating lbaas in mitaka as a first step. any idea when it will move forward?
17:32:43 <HenryG> I am working on adding tests, and double-checking with salv-orlando that it makes sense
17:33:02 <HenryG> I'll post a new patch soon, which should be close to final
17:33:33 <dougwig> great.
17:33:54 <HenryG> kevin should take a close look too
17:34:02 <dougwig> i'll be working on model abstraction and rpc next. the last big piece will be dealing with the agent goo.
17:34:52 <dougwig> HenryG: are you going to make it to the midcycle?
17:35:02 <HenryG> yes
17:35:02 <pc_m> hi
17:35:10 <dougwig> hiya
17:35:15 * pc_m sorry - late
17:35:30 <dougwig> no worries
17:35:34 <dougwig> #topic Open Discussion
17:35:45 <dougwig> any items here, or i'll go back to doing truly unholy things to python to make henry happy.
17:36:11 <HenryG> :)
17:36:25 <pc_m> I have some BW to do more neutron-lib stuff.
17:37:15 <dougwig> pc_m: want to rehab the rpc move patch, or start tackling deprecation warnings, or separate unit tests, or ... ?
17:38:17 <pc_m> dougwig: sure... just need to know what things need to be done and roughly what we're looking to do.
17:39:11 <pc_m> sould use a little background on what those items are.
17:39:15 <pc_m> could
17:40:11 <dougwig> rpc patch is this one: https://review.openstack.org/#/c/273909/  ... needs to address the comments that were put into the earlier patchsets of https://review.openstack.org/#/c/267807/
17:40:50 <dougwig> addressing deprecation warnings is stadium-wide, and needed after https://review.openstack.org/#/c/268232/ ... look at the unit test output in that patch to see what i mean.
17:41:12 <dougwig> and separating unit tests means making the advanced services not 'import neutron' anywhere under tests/
17:41:59 <pc_m> dougwig: On that, so we inherit tests currently. Is the (short term?) goal to clone those tests?
17:42:27 <pc_m> dougwig: seems like a nightmare to keep them in sync.
17:42:27 <dougwig> you mean dup the test base class?  yep, most likely. minus the extra bits it's not using from the original.
17:42:53 <dougwig> well, let's back up.  is that the best approach?  and if so, do they need to stay in sync if they're separate units?
17:44:47 <pc_m> dougwig: all good questions...that I don't have an answer on.
17:45:33 <dougwig> want to look into the units of vpn/fw/lb this week and take a first stab at answering them?
17:45:50 <pc_m> I know our company is going through daily breakages in tests, because of neutron changes right now.
17:45:56 * pc_m in a plugin
17:46:04 * pc_m not *aaS
17:47:09 <pc_m> dougwig: I can try to look at it. Not sure if I have any ideas though.
17:47:26 <dougwig> is there a way to insulate your tests, or is it actual neutron breakages?  and which modules?
17:48:23 <pc_m> In this case, they are tests that are inheriting tests from Neutron. The neutron code for the test has changed (and works), but the vendor code is now boken.
17:49:09 <pc_m> Latest case is a change to L3 plugin, method made private. Vendor L3 plugin doesn't have the method (or use the same Neutron base class).
17:49:10 <HenryG> TBH I am not sure how I feel about neutron-lib being a lib for tests
17:50:09 <pc_m> HenryG: Isn't dougwig talking about placing the tests in *aaS and not neutron-lib?
17:50:39 <HenryG> pc_m: maybe, but that would be a lot of duplicated code
17:50:43 <dougwig> HenryG: what i discussed way back when with maru was to simply dup the neutron unit base classes into the services, and either let them diverge or sync them occasionally. but basically let the tests in a repo stand on their own. because i honestly don't expect any stable interface there from neutron.  and if we do add that to neutron-lib someday, well,
17:50:43 <dougwig> that's a different story that i'm not sure needs tackling today.
17:51:25 <dougwig> HenryG: well, you have to pick one. in the lib or dup.
17:51:26 <pc_m> HenryG: yeah, that is my concern
17:51:29 <dougwig> right?
17:51:37 <HenryG> Yep, my git feeling right now is NOT in the lib
17:51:48 <dougwig> pun intended?
17:51:50 <HenryG> gut even
17:52:07 <pc_m> --rebase
17:52:12 <pc_m> :)
17:52:23 <dougwig> if they're truly units, i wonder if they even need all that plugin goo nonsense.  units should just be testing the func/method in question, as opposed to that quasi-api mess in neutron.
17:52:34 <dougwig> but *that* refactor is a per-repo decision, IMO.
17:52:53 <HenryG> dougwig: you went there
17:53:04 <dougwig> weren't we all dancing around it?
17:53:08 * HenryG stears clear
17:53:14 <pc_m> dougwig: I suspect that is the case... that the test aren't really unit tests.
17:53:26 <HenryG> steers even. I can't spell today
17:53:51 <HenryG> pc_m: that is a known fact
17:55:30 <dougwig> so, we have some seriously non-unit unit test goo. do we want to spend time worrying about how to derive them cleanly when they're not great in the first place, or get the dependency severed and put a pin in "yo, make better tests y'all" ?
17:55:38 <dougwig> that's where i always end up.
17:56:45 <pc_m> latter seems better, to me. But that's assuming someone is there to do the cleanup.
17:56:55 <HenryG> Like I said, my current feelings lean towards not providing any tests lib yet
17:57:33 <dougwig> HenryG: and i think i just talked myself into fully agreeing, since propagating the current base will propagate the current unit structure.
17:58:22 <HenryG> dougwig: Right. If the repos clone the base test classes and diverge, perhaps we can learn something from the ways in which they diverge, and go from there.
17:58:58 <dougwig> pc_m: want to try it in vpn and let us know how it goes?
17:59:12 <pc_m> OK. I can give it a whirl.
17:59:21 <dougwig> or fw or lb. your choice, really.
17:59:22 <dougwig> ok.
17:59:37 <HenryG> pc_m: and/or in your vendor repo
17:59:38 <dougwig> any other items to discuss today, or shall we get 30 minutes back?  we could bikeshed the stadium for awhile.
17:59:40 <pc_m> VPN is small
18:00:03 <pc_m> Cisco repo would be even better (my mgmt would like that).
18:00:16 <pc_m> dougwig: A few quick things...
18:00:36 <pc_m> What do we plan on doing with 242219? Is the plan to get that passing tests?
18:01:13 <pc_m> If not, how do we use neutron-lib for things like validators. converters, callbacks...?
18:01:43 <dougwig> pc_m: if units and api pass, that is pretty good coverage.
18:01:47 <dougwig> re: 242219.
18:02:37 <pc_m> I had done those three in neutron-lib, but they need to be used in Neutron and *aaS. If the commits base off of 242219, how do we upstream (w/o tests passing)?
18:02:47 <dougwig> i'd ignore the other fails until the patch is actually ready to merge. you're not adding much.  the scenarios and dvr.
18:03:23 <dougwig> pc_m: i've been using 242219 as a base, and then undoing it and going direct when the lib change is ready. i don't intend to ever merge 242219.
18:03:34 <dougwig> that's what happened with https://review.openstack.org/#/c/268232
18:04:01 <pc_m> so... base changes on 242219, then if tests look ok, reapply to master w/o 242219?
18:04:50 <dougwig> pc_m: aye. i'd also though about adding the tempest-neutron-from-source-neutron-lib job to the neutron experimental queue as an alternative, but that's just tempest, not the units.
18:05:33 <pc_m> On the callback feature I migrated. I have an idea for using OVO, and have been playing with some prototype code.
18:06:10 <pc_m> Should I A) post that and see what people think of the concept, B) do a blueprint or RFE, or C) something else?
18:06:44 <pc_m> B) or devref
18:07:01 <HenryG> I am a little wary about pulling OVO into neutron-lib since it is so new
18:07:23 <dougwig> a wip to share an idea never hurts, though.
18:07:24 <pc_m> HenryG: It wouldn't be really in neutron-lib
18:07:59 <HenryG> pc_m: OK, post a wip and I'll take a look
18:07:59 <pc_m> HenryG: It's just that the resources it deals with would be OVOs that Neutron is currently generating.
18:08:07 <pc_m> HenryG: OK.
18:08:17 <pc_m> dougwig: Lastly, and a bit off-topic...
18:08:32 <pc_m> Do we want to move all *aaS to using constraints jobs?
18:09:14 <dougwig> yes, but as per the tc all regular jobs should start using constraints.  so py27, not py27-constraints.
18:09:22 <pc_m> If so, it sounds like the TC wants us to use the existing jobs and redefine them as cosntraints based, rather than create new jobs (as I did in neutorn-vpnaas, and neutron has done).
18:10:21 <pc_m> I can move forward again with the work I had started. Just didn't want to do that, without ensuring that was a community desire.
18:10:56 <dougwig> i think it's gradually going to be a cross project requirement.
18:11:55 <pc_m> I think Ihar was wondering about how to allow non-constraints runs as well, in case one wanted to test a new lib version or something. Useful?
18:12:37 <pc_m> Maybe we can use some env var to somehow skip using the constraints and use requirements.txt? Not sure yet on how best to do that.
18:13:42 <dougwig> or an env var to override where to fetch the constraints file.  i recently added that to the lbaas tox_install, so i could fetch neutron from a local directory on the plane.
18:14:19 <pc_m> that's even better. good idea!
18:15:05 <dougwig> ok, we done for today?
18:15:32 <pc_m> yes from me.
18:15:34 <dougwig> away we go...
18:15:35 <dougwig> #endmeeting