17:30:14 <dougwig> #startmeeting networking_lib
17:30:15 <openstack> Meeting started Wed Jun 29 17:30:14 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:30:18 <dougwig> hi all.
17:30:19 <openstack> The meeting name has been set to 'networking_lib'
17:30:27 <dougwig> #topic Announcements
17:30:58 <dougwig> new core reviewers -- starting last night, anyone neutron stadium core can +2, and any driver can +A.  please be aware of the public interface rules, especially when merging.
17:31:23 <HenryG> Most of the rules are in the devref.
17:31:33 <dougwig> for anyone doing releases, which is usually me or HenryG, we need to come up with a script or something to audit the new interfaces. more cooks means more merging, and once it hits pypi, we're stuck with it for literally years.
17:32:24 <boden> are there existing scripts that do this elsewhere that you know of?
17:32:55 <dougwig> no, or i'd have used them to add a unit test to prevent destructive interface changes.  :)
17:33:20 <boden> I can take a stab at such a script if you like
17:33:49 <dougwig> pleaes.
17:33:52 <dougwig> please
17:34:11 <dougwig> another announcement, ireland is approaching.
17:34:15 <dougwig> #topic  hacking check policy
17:34:19 <dougwig> boden, you have the floor
17:34:34 <boden> #link https://review.openstack.org/#/c/333500/
17:35:05 <boden> there’s some discussion about how we proceed with new hacking checks that might break consumers who use our checks.factory()
17:35:49 <boden> the obvious: consumers break and ignore (via flake8) until they can comply
17:36:00 <boden> any other ideas?
17:36:37 <HenryG> IMO it is kind of OK to break such things since it does not break anything user-facing
17:36:46 <dougwig> that's not very library friendly, though.
17:37:09 <HenryG> But the goal is to get our library into a friendlier form
17:37:18 <dougwig> we could make an internal private factory and an external one.
17:37:24 <boden> is this a call for a mini-interface around our checks :)
17:37:49 <dougwig> as a dev, if "pip install -U" breaks me, i get annoyed. maybe that's just me.
17:38:12 <boden> agreed, but on the other hand the check goes un-noticed
17:38:36 <dougwig> those checks serve two purposes...  checking the lib code itself, and providing reuse for subprojects (especially the 'no neutron' check.)
17:38:49 <dougwig> right, and this is a neutron library, so i guess we're allowed to be a bit opinionated.
17:38:58 <dougwig> and they can always opt to not use the neutron-lib checks at all.
17:39:08 <dougwig> or use their own factory.
17:39:17 <boden> yep, today we have a large amount of folks using it
17:39:20 <boden> fyi
17:39:47 <dougwig> we could run a few key pep8's, like neutron, on every change. it'll make it hard to merge hacking checks, since it'll be a two-step shuffle.
17:40:05 <boden> dougwig I was thinking that too
17:40:15 <boden> I’d at least like to know if neutron pep8 breaks
17:40:25 <dougwig> i was already looking into running neutron's unit tests last night, so this would be similar.
17:41:18 <boden> does it make sense to perhaps build a small API aound our checks to make it easier for consumers to use them, or just assume they can use the public check functions as they see fit?
17:41:44 <dougwig> i personally think the latter is fine.
17:41:57 <boden> works for me
17:42:28 <boden> so we should probably doc this approach (devref) to get some further input during the patch review
17:42:37 <boden> this approach == for hacking checks
17:43:07 <boden> I’ll make sure 333500 has such details
17:43:09 <dougwig> ok, that works.
17:43:38 <boden> next topic, I think
17:43:43 <dougwig> #topic new target project to deliver as part of our newton work since lbaas now has a spin-off
17:44:13 <dougwig> this came up this past week; with lbaas moving into octavia, it likely isn't a good target for the initial pass of the lib.
17:44:18 <HenryG> Which are the candidates?
17:44:28 <dougwig> we can pick another *aas, though they will likely fare similarly; perhaps an ml2 driver?
17:45:03 <HenryG> How about a networking-foo that's in the stadium?
17:45:13 <dougwig> this is the list that i work against when making a lib change:
17:45:16 <dougwig> https://www.irccloud.com/pastebin/QsoIDs4N/
17:45:35 <boden> I was thinking we should use a stadium proj?
17:45:42 <boden> https://github.com/openstack/neutron-specs/blob/master/specs/newton/neutron-stadium.rst
17:45:53 <dougwig> i would say ovn, but they're a core plugin, not ml2
17:46:19 <HenryG> ovn is now ml2
17:46:26 <HenryG> they converted
17:46:38 <dougwig> how about ovn and l2gw as the new targets?
17:46:41 <boden> networking-l2gw?
17:46:45 <dougwig> jinx
17:47:03 <HenryG> sounds good to me
17:47:23 <HenryG> We can keep an eye on dynamic-routing too
17:47:34 <boden> works for me
17:47:42 <dougwig> ok, sounds like a decision
17:47:54 <HenryG> +1
17:48:00 <boden> +1
17:48:00 <dougwig> #topic Do we really want to run with the forbid eventlet patch
17:48:14 <HenryG> armax approved it
17:48:16 <boden> I’m more curious about this than anything else :)
17:48:17 <dougwig> in the lib, i think the answer is yes.
17:48:40 <dougwig> though eventlet now supports py3, so maybe it's not as evil as others thought it was.
17:48:58 <dougwig> moving on
17:49:04 <dougwig> #topic neutron-lib callbacks and OVO
17:49:07 <dougwig> who's was this?
17:49:16 <boden> dougwig: me
17:49:27 <dougwig> the floor is yours
17:49:40 <boden> I think the bullet in the wiki sums it up
17:49:51 <boden> paste—> I'm going to try and kick the tires a bit more on neutron-lib callbacks. In particular I'm thinking of proposing a backwards compatible change in neutron that can use OVO. The thought is to get neutron on-board with a new callback API that can support OVO, then get that support into neutron-lib, etc. For example 279734 that Paul did, but no longer has bandwidth to drive.
17:50:02 <boden> thoughts?
17:50:12 <dougwig> i would suggest pinging armax and getting his thoughts on this one.
17:50:17 <boden> ack
17:50:19 <HenryG> boden: sounds good to me, but keep in close sync with armax
17:50:35 <dougwig> definitely an area that needs tackling.
17:50:58 <boden> sounds good; thx
17:52:08 <dougwig> #topic Open discussion
17:52:15 <dougwig> HenryG: is the base db stuff in yet?
17:52:59 <HenryG> No, I am preparing a patch for neutron core first, because some things need to be shuffled there
17:53:41 <dougwig> ok.  let us know when it's there.
17:53:48 <HenryG> Shuffling after moving to lib is fraught with perils
17:53:54 <dougwig> anything else today?
17:54:04 <HenryG> Just a quick note on api-ref
17:54:18 <HenryG> We should add it as a weekly topic
17:54:37 <HenryG> Akihiro is driving it
17:55:13 <boden> admittedly I need to read up on that topic :)
17:55:47 <boden> nothing else from me
17:56:12 <boden> oh, I’ll be out next Monday
17:56:19 <HenryG> The work is going to be a lot of low-hanging-fruit to get all the APIs correctly documented.
17:56:20 <boden> and perhap Tuesday; but not sure on Tue
17:56:27 <dougwig> HenryG: ok, i don't see amotoki online.  any update on api ref?
17:56:51 <HenryG> Last I heard he is preparing an example on how to update/correct an API.
17:57:17 <boden> https://review.openstack.org/#/c/330890/
17:57:23 <HenryG> From that template folks can go wild I assume
17:57:54 * njohnston has an item, if now is a good time
17:57:54 <dougwig> we might need to adjust this meeting time if he needs to attend.
17:58:09 <dougwig> given that it's 3am where he is.
17:58:30 <HenryG> ack, I will check with him
17:59:10 <dougwig> alright, let's get out of here.
17:59:12 <dougwig> #endmeeting