17:31:04 <dougwig> #startmeeting networking_lib
17:31:05 <openstack> Meeting started Wed Jul 13 17:31:04 2016 UTC and is due to finish in 60 minutes.  The chair is dougwig. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:31:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:31:06 <dougwig> boden: aye
17:31:09 <openstack> The meeting name has been set to 'networking_lib'
17:31:12 <HenryG> o/
17:31:14 <johnsom> o/
17:31:16 <boden> o/
17:31:28 <dougwig> #topic Announcements
17:31:41 <kevinbenton> Hi
17:31:56 <dougwig> we've grown beyond my envelope planning, so if you could all help me fill this out today and going forward: https://etherpad.openstack.org/p/nl-planning
17:32:30 <HenryG> ack
17:32:43 <dougwig> moving on, looks like boden gave us a nice agenda.
17:32:47 <dougwig> #topic feedback on the high-level approach for a public python API generation tool
17:32:58 <dougwig> #link https://review.openstack.org/#/c/338571/
17:33:10 <HenryG> I have not had time to look at it in any depth
17:33:36 <dougwig> boden: anything you want to add here?  else we'll just let this serve as raising visibility for later feedback.
17:33:39 <boden> HenryG: when you do, really the only depth I’m looking for is to read the commit message + links and provide feedback
17:33:50 <boden> don’t look at code… scarry stuff in there!
17:34:15 <HenryG> was that a deliberate typo? :)
17:34:15 <boden> nothing else; pls just have a look when you get a min
17:34:49 <boden> never!
17:34:56 <dougwig> ok, next
17:34:59 <dougwig> #topic release cadence
17:35:10 <dougwig> looks like boden wants more frequent releases?
17:35:27 <HenryG> I am OK with that, but ...
17:35:57 <HenryG> There is some infra plumbing still pending to allow checking against neutron-lib master
17:36:40 <HenryG> Until all those bits land, we have a hard time guaging the impact of adopting a new neutron-lib release
17:36:53 <boden> HenryG: where is that plumbing; in neutron-lib gate?
17:37:21 <HenryG> boden: it's in infra/project-config
17:37:26 <dougwig> armax has been working on adding periodic jobs
17:37:37 <dougwig> modeled after how oslo has done it
17:37:44 <boden> I see
17:37:50 <armax> dougwig: one patch is still outstanding
17:37:57 <boden> +1 on that; we need it IMO
17:38:26 <dougwig> what modules are you wanting released, specifically, btw?
17:38:33 <HenryG> And then there's the manual recipe, which fails grenade currently
17:39:15 <boden> dougwig: nothing per say. I’m more so kicking the topic of “is it easier for adopters/contributors if we have more frequent releases”
17:40:03 <boden> this is likely related to the last bullet on the agenda
17:40:06 <dougwig> ok, i'm personally not in a hurry until we get the tests in place to make sure we don't regress.
17:40:16 <HenryG> dougwig: +1
17:40:23 <boden> dougwig: agree. we need to get the right plumbing in place
17:40:44 <dougwig> let's keep progressing on that front and revisit this, then.
17:40:47 <dougwig> next
17:40:49 <dougwig> #topic neutron pep8 jobs running for neutron-lib gate
17:40:59 <dougwig> armax: is that job part of your periodic batch?
17:41:09 <armax> dougwig: nop
17:41:32 <dougwig> ok, it's likely the same template, so i'll wait until you're done, then we can add it.
17:42:02 <armax> dougwig: something to think about
17:42:35 <armax> dougwig: running pep8 against neutron-lib can alert folks of new hacking checsk
17:42:39 <armax> checks
17:42:49 <armax> but I’d be less inclined to think that’s useful
17:42:53 <armax> on a periodic basis
17:43:22 <dougwig> i'm fine running units and pep8 on every lib patchset, personally.
17:43:31 <boden> dougwig: +1
17:44:21 <armax> dougwig: I just don’t want to abuse the infra tool
17:44:33 <armax> unless it’s useful to catch unexpected brekages
17:44:42 <armax> the planned ones can be tackled with communication
17:44:54 <dougwig> armax: unit jobs are cheap; i'd expect we can even run all of pep/py27/py34 for multiple repos on a single node, so it's just tox for all of them.
17:45:07 <dougwig> and still keep that node well under the runtime of the neutron full job
17:45:10 <armax> dougwig: cheapness is not the point
17:46:14 <dougwig> we already broke the world once with new hacking checks, which is where this originated
17:46:41 <boden> I’d love to see a way we can trigger a lib master build against a target project(s), say for prep of lib release
17:47:02 <armax> dougwig: I would hope that was intentional :)
17:47:48 <boden> growing pains
17:48:01 <dougwig> armax: ha, the 'never import neutron' check might've been a wee bit premature to automatically enable itself everywhere.
17:48:20 <armax> dougwig: duh!
17:48:20 <armax> :)
17:48:22 <dougwig> the subprojects inherit the checks from neutron master, but not the exclude list.
17:48:29 <dougwig> which is obvious in hindsight.
17:49:02 <dougwig> alright, armax and i can discuss this once the periodics are working.
17:49:03 <dougwig> next
17:49:05 <dougwig> #topic "documenting public APIs with pydoc string"
17:49:08 <dougwig> boden, this one is yours
17:49:09 <armax> dougwig: aye
17:49:32 <boden> #link https://review.openstack.org/#/c/340580/
17:49:35 <boden> there, done :)
17:49:37 <HenryG> It's RST not pydoc, but I think we are in agreement
17:49:50 <boden> HenryG: patch already updated
17:50:07 <HenryG> I don't think we need to discuss here
17:50:10 <boden> nope
17:50:42 <armax> I just gave it a -1
17:50:45 <armax> btw :)
17:50:52 <dougwig> haha, good old armax.
17:50:53 <boden> armax: how dare you!
17:51:05 <dougwig> #topic "general process of 'letting code back' in its source project before rehoming to neutron-lib can be a bit of a catch22"
17:51:12 <dougwig> boden: want to explain this one?
17:51:17 <armax> boden: you don’t know me well enough
17:51:42 <armax> boden: if you had started working on neutron first you’d know I dare very much
17:51:56 <boden> simply stated - I’d like to tell people getting stuff into neutron lib can be fast and easy… today’s its slow and confusing
17:52:37 <dougwig> neutron people or subproject people?
17:52:50 <dougwig> and is 'fast' code for 'submit to lib, use from lib directly' ?
17:53:38 <HenryG> I think it's almost always going to be slowish because we have to be very careful.
17:53:41 <boden> example: often we are telling people in neutron patch reviews that it need to go into lib. So they try to get into lib and we tell them it must bake in neutron 1st, and even if you get it into lib it’ll be awhile to get a release
17:54:35 <boden> ok: so is it a case-by-case basis if it need to bake in the source project before comming into lib, or is it a blanket “bake it in your project first”?
17:54:48 <HenryG> So I think we should stop telling people that new code should go directly to lib.
17:55:25 <boden> HenryG: no objections; I just want to make sure we are all on the same page + in some agreement
17:56:04 <boden> I don’t hear anyone complaining that we make it bake in the source project.. turn that oven on ;)
17:56:06 <njohnston> So let's say I am adding an interface between neutron and other projects, like the l3 agent extension stuff.  Other projects use it.  Then it gets shifted into neutron-lib.  Do we need to drop deprecation notices where it was implemented originally?
17:56:48 <armax> HenryG: who make such statements?
17:57:16 <HenryG> armax: I may have implied some things when I was still a lib n00b.
17:57:31 <armax> HenryG: I think the statement can apply depending on the context
17:57:34 <boden> I may be guilty as well
17:57:58 <njohnston> armax: That was how I read your comment in https://review.openstack.org/#/c/329701/5/neutron/agent/l3/l3_agent_extension.py initially
17:58:18 <HenryG> armax: everything depends on context
17:58:55 <armax> njohnston: I obviously clarified what I meant
17:58:56 <dougwig> so this one boils down to us all being horrible human beings?
17:58:59 <armax> njohnston: having said taht
17:59:20 <armax> incubating code on the periphery may be counterproductive
17:59:42 <armax> library development doesn’t have to happen in a sandbox
17:59:43 <armax> necessarily
18:00:14 <armax> so for new code, I am not sure that ‘go over there and play with it first’ approach makes sense
18:01:22 <armax> in the context of a library review we can judge whether code is well written, and for that a probation period doesn’t help necessarily
18:01:43 <armax> on the contrary it makes things more cumbersome than they need to be
18:02:53 <HenryG> The problem with bugs in lib code though, is that it is slow getting the fix out to the affected parties.
18:03:26 <HenryG> That's why I see the benefit of incubation to get past the initial bugs.
18:03:33 <boden> HenryG: that’s why I was kicking the “faster release” topic. or at least 1 motivation
18:03:41 <armax> oslo has bugs
18:03:45 <armax> libraries have bugs
18:03:48 <armax> software has bugs!
18:03:59 <armax> there’s no escape
18:04:05 <HenryG> even your code? :)
18:04:08 <armax> yes
18:04:13 <armax> my code first and foremost!
18:05:19 <boden> imo if we can release faster it shouldn’t be a big deal per say; fix and release
18:06:05 <dougwig> boden: note that to do a release we must: 1) review the interface changes (no problem), 2) make a release patch (no problem), 3) wait for the release patch to merge (out of our hands), 4) wait for it to publish to pypi and propagate (out of our hands), 5) submit requirements patch, 6) wait for g-r to merge (usually a LONG delay), 7) wait for proposal bot to
18:06:05 <dougwig> propagate.  that isn't a process that can go fast in terms of latency of a single patch.
18:06:46 <boden> so 3-7 is days or weeks?
18:06:56 <HenryG> This happens to oslo, and armax says that is OK
18:07:25 <dougwig> i've had 6) take weeks.  even longer if it's a milestone freeze.
18:07:26 <armax> I am saying that it’s how it is, now it’s one thing to deal with 1 bug, another is dealing with 100
18:07:38 <kevinbenton> neutron-lib isn't the same as oslo. we have very specific neutron logic in the lib
18:07:49 <kevinbenton> so it's very coupled to neutron feature development
18:08:12 <armax> kevinbenton: is that a metaphore for saying we suck at writing code?
18:08:24 <armax> kevinbenton: that might as well be a point very well made
18:08:49 <kevinbenton> no, i'm just saying the turnaround of waiting for releases is very cumbersome for neutron development
18:08:49 <armax> writing as well as reviewing, mind you
18:09:02 <dougwig> i think he's saying that an ml2 port interface needing a new parameter for its models isnt' the same as a string parser.
18:09:12 <dougwig> /that an/that adding an/
18:09:28 <kevinbenton> oslo is stuff that is orthoganally related to the actual tasks at hand
18:09:29 <dougwig> man, my fix made the grammar even worse.
18:09:42 <armax> dougwig: I think there are two issues
18:09:48 <armax> one issue is to design a good interface
18:09:54 <armax> the other is to implement a good interface
18:10:07 <armax> bugs can affect both
18:10:19 <armax> I am not so worries about the latter compared to the former
18:10:25 <armax> we gotta nail the former
18:10:45 <armax> and for that I don’t think that baking in a sandbox is necessarily the right thing to do every time
18:10:53 <boden> armax: +1
18:11:20 <armax> and my second point should be rewritten as
18:11:36 <armax> do a good implementation of the aforementioned interface
18:11:37 <dougwig> armax: i'd agree with that. i'd also have no problems, personally, submitting an interface as a lib review at the same time i submit the same thing in neutron, and if they diverge, reconciling later.
18:11:58 <kevinbenton> dougwig: that's because you don't develop neutron interfaces :P
18:12:52 <kevinbenton> most of our interfaces are a complete disaster initially
18:13:04 <kevinbenton> and we figure out better stuff even in quick follow up patches
18:13:04 <HenryG> So what is the magic recipe for designing a good interface?
18:13:13 <dougwig> kevinbenton: "initially" ?  :)
18:14:20 <dougwig> ok, so we've scoped the issue. does anyone have any preferences as to how we adjust our process to make things better, if anything?
18:15:08 <njohnston> Just one point of clarification: do we follow standard interface deprecation policy when we shift something from neutron to neutron-lib?
18:16:40 <njohnston> So let's say I have a brand new interface (I have the l3 agent extensions in mind), and it bakes in neutron for a cycle, then it'll have deprecation warnings for the next two.  I think this is how it works, but I want to be sure.
18:16:52 <dougwig> njohnston: no. neutron is not meant to be an interface. we will automatically fix stadium projects that we break, but outside, it's the wild west.
18:17:48 <njohnston> I see, that simplifies things a bit.  Thanks.
18:17:57 <HenryG> I agree. Deprecation only for existing stuff.
18:18:12 <dougwig> that was me drawing a line in the sand.  feel free to disagree.  :)
18:18:38 <njohnston> No, I think it lowers the level of cognitive dissonance on my part, so I like it.
18:18:51 <HenryG> dougwig: Perhaps send an email drawing N-2 as the line?
18:19:08 <dougwig> are you concerned that fwaas using the interface in neutron will be broken?  because unless you're planning for mismatched server release versions of neutron vs fwaas, i don't think it's possible to get into trouble with my statement above.
18:19:59 <njohnston> No, I was thinking in general terms, because once it's released I don't know who is going to come in and want to use the interface.
18:20:22 <dougwig> i'll just point at hacking rule N530, which counts double for anything new.
18:21:02 <dougwig> HenryG: i didn't follow that.
18:21:25 <njohnston> according to N530 the l3 agent extensions should be developed in neutron-lib from inception
18:22:34 <dougwig> so if we imagine ourselves three releases from now, yes, that's true. is what it's being done of top of moved at that point, too?
18:22:44 <njohnston> at least, assuming FWaaS will be subject to N530, which I assume is the case
18:24:39 <dougwig> do we see a problem there, or just pointing it out?
18:25:02 <HenryG> dougwig: I meant an email announcing that subprojects consuming any neutron code added after N-2 will be SOL.
18:25:45 <dougwig> (almost out of time today)
18:26:17 <njohnston> dougwig: Let me hit you up after, if that's OK.  I feel like there is something I am missing.
18:26:23 <dougwig> ok
18:26:28 <dougwig> HenryG: ok
18:26:31 <dougwig> #topic Open discussion
18:27:13 <johnsom> FYI, HenryG this just needs rebased:https://review.openstack.org/#/c/337268
18:27:20 <dougwig> boden: i skipped your covered topic, as that just looks like a bug.
18:27:59 <HenryG> I think it was an infra blip. Works fine for new jobs
18:28:18 <HenryG> johnsom: ack
18:28:51 <boden> dougwig: what bug? sorry I missed context
18:29:14 <dougwig> boden: will follow-up after
18:29:22 <boden> dougwig: ack
18:29:23 <dougwig> looks like HenryG answered, though
18:29:32 <dougwig> #endmeeting