17:33:53 <dougwig> #startmeeting networking_lib 17:33:54 <openstack> Meeting started Wed May 25 17:33:53 2016 UTC and is due to finish in 60 minutes. The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:33:54 <dougwig> hi all 17:33:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:33:58 <openstack> The meeting name has been set to 'networking_lib' 17:34:00 <armax> here 17:34:02 <armax> and not here 17:34:42 <dougwig> haha, hi armax. 17:34:46 <dougwig> #topic Brief status 17:34:52 <dougwig> boden, how goes the agent stuff? 17:35:03 <boden> I have 3 patches out for review 17:35:42 <boden> And a few more I could throw out there as well, but have been waiting for a few others to merge to reduce a (patch) dependency chain 17:35:52 <boden> That’s what I got : ) 17:36:01 <dougwig> are they all ready for review, or still wip? 17:36:08 <boden> they are ready 17:36:21 <HenryG> ok, I will start reviewing 17:36:26 <boden> if a WIP I already try to put that in the commit subject 17:36:32 <boden> ok thanks 17:36:33 <dougwig> ok, good. 17:36:48 <dougwig> henry, you were going to rebase your db stuff? 17:37:14 <HenryG> the context & policy patch is rebased 17:37:45 <boden> I think I had some outstanding comments on the your db patch HenryG 17:38:22 <HenryG> the db one I am still working on to avoid OVO implications 17:38:47 <dougwig> alright, let's get to a fun topic 17:38:51 <dougwig> #topic Gate jobs 17:39:03 <dougwig> we had the 0.2.0 release this week, and it busted neutron. 17:39:16 <dougwig> armax and i discussed gating the lib on more of the neutron jobs. 17:39:26 <dougwig> any objections or comments to that? 17:39:36 <HenryG> +1 17:39:45 <boden> agreed +1 17:40:13 <dougwig> i have cycles to look at that next week, unless someone wants to pick up the torch sooner? but i'm dang well taking memorial day weekend off. :) 17:40:33 <dougwig> what jobs should we add? definitely unit. we already do -full. 17:40:51 <HenryG> not functional, too flakey 17:40:54 <boden> dougwig I don’t mind helping where I can, but maybe a little slow to ramp-up 17:41:24 <kevinbenton> Can we just add them all as periodic or experimental? 17:41:26 <dougwig> boden: thanks, and no worries, you help with the reviews to get to know how those pieces work. 17:41:27 <armax> dougwig: unit would suffice, HenryG and I thought about a couple of strategies 17:41:29 <kevinbenton> We K 17:41:38 <dougwig> armax/HenryG - shoot 17:41:43 <kevinbenton> We only really need to pay attention at release 17:41:59 <dougwig> kevinbenton: i'd prefer that master was always pullable, IMO. 17:42:09 <armax> dougwig: one step is getting unit tests to co-gate 17:42:38 <armax> dougwig: this is inline with what is suggested in the stadium spec too 17:42:40 <dougwig> armax: by co-gate, you mean running lib unit tests for neutron changes? 17:42:55 <armax> dougwig: no, the otehr way around 17:43:03 <dougwig> ok, yes, definitely. 17:43:04 <armax> dougwig: running neutron’s unit tests on neutron-lib changes 17:43:17 <dougwig> arguably we should run all stadium project unit tests. 17:43:24 <armax> dougwig: we could do so on a periodic basis rather than a check basis 17:43:31 <armax> dougwig: but that’s splitting hair 17:43:39 <dougwig> unit tests are cheap/fast compared to the -full that's already in there. 17:43:47 <armax> dougwig: indeed 17:43:54 <dougwig> we can also likely make a job that runs all the projects unit tests in one job. 17:43:55 <armax> dougwig: however, when it’s time for a release 17:44:13 <armax> we may be potentially break other projects too like functional, fullstack, grenade, multi 17:44:44 <armax> dougwig: and it would be nice if we could figure out a way to test the whole lot at once before we pull the trigger during a release 17:45:05 <armax> eventually the level of decoupling will be adequate enough that we no longer need that 17:45:08 <dougwig> sort of a 'check release' type thing? i'm sure we could abuse experimental for that. or run them all the time. 17:45:17 <armax> dougwig: indeed 17:45:30 <dougwig> will infra add a new pipeline for that, i wonder? 17:45:39 <armax> dougwig: something along those lines, I think I need a little more brainstorming on the actual strategy though 17:45:49 <dougwig> i'm not opposed to running all of the neutron jobs on every change, to be honest. 17:45:55 <armax> dougwig: we could gauge the appetite 17:46:05 <armax> dougwig: they have an experimental-tripleo one 17:46:14 <armax> dougwig: but it might not be necessary 17:46:35 <armax> dougwig: for neutron-lib you mean? 17:46:44 <dougwig> dhellmann: are you around? are there any provisions for doing an extra big set of test jobs prior to a lib release, or are they usually all just put into check/gate and run every time? 17:46:55 <dougwig> armax: yes. 17:47:05 <armax> dougwig: it seems like an overkill 17:47:33 <armax> dougwig: until a new release any change is ineffective 17:47:49 <dougwig> armax: unless you run master. 17:48:05 <armax> dougwig: no-one would run neutron-lib master 17:48:55 <dougwig> i thought that about neutron, too. 17:49:03 <armax> to start off running unit tests on check (or periodic) would suffice, then we can iterate and plug any remaining hole as it shows up 17:49:43 <dougwig> i'd vote for unit tests in check, because they're quick/cheap. 17:49:51 <armax> in the meantime if we can figure out a way to check the effect of a new release on a ad hoc basis 17:50:06 <armax> for all neutron’s jobs that’s a bonus 17:50:28 <armax> dougwig: ok, I was going to put that together, unfornately it’s not that simple than adding a single line to project-config 17:50:53 <HenryG> why not? 17:51:00 <dougwig> armax: no, because you need the repo on disk, and to not pull requirements. i know how to set those up, though. 17:51:10 <armax> HenryG: ^ 17:51:12 <armax> dougwig: ack 17:51:19 <HenryG> hmph 17:51:21 <armax> we’d need to do something like the periodic oslo jobs 17:51:27 <armax> dougwig: right? 17:52:28 <dougwig> for devstack, you use LIBS_FROM_GIT. for unit, i forget what i did. but i usually use the oslo templates when i can (which is what the master/master job in neutron experimental is using.) 17:52:51 <armax> dougwig: ack 17:53:04 <armax> so maybe you and I can reconvene later offline to agree on who does what 17:53:10 <dougwig> ok, sounds good. 17:53:18 <armax> dougwig: thanks 17:53:28 <dougwig> my only invariant is that i *am* installing solar on the roof of my RV this weekend. 17:53:45 <dougwig> :) 17:53:48 <armax> dougwig: who said I was going to work over the weekend? 17:54:01 <dougwig> that's been my last two months. 17:54:05 <dougwig> #topic Open discussion 17:54:08 <dougwig> any other topics for today? 17:54:24 <boden> nothing from me 17:54:45 <HenryG> Enabling depends-on: a neutron-lib patch in neutron 17:55:12 <HenryG> The whole tox_install.sh thingy 17:55:28 <HenryG> Can it be done? 17:56:07 <dougwig> so you run the units with non-pypi lib, i take it? 17:56:35 <dougwig> it'd be easier to flip the arrow and put the jobs on the lib side, so we have that mess in one spot. 17:59:11 <HenryG> yeah, that makes sense 18:00:37 <HenryG> nothing else from me 18:03:33 <dougwig> ok, let's blast out of here. 18:03:35 <dougwig> #endmeeitng 18:03:39 <dougwig> #endmeeting