17:30:10 #startmeeting networking_lib 17:30:10 Meeting started Wed Jun 22 17:30:10 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:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:30:14 The meeting name has been set to 'networking_lib' 17:30:18 #topic Open discussion 17:30:25 I can almost taste the guinness. Can you? 17:30:38 heh 17:30:42 almost :) 17:30:50 #link https://review.openstack.org/#/c/324090/ 17:31:18 I am torn. 17:31:25 raises concern about changing public facing APIs/vars 17:31:50 I like the change, but if we break someone we will be hated. 17:32:10 so, i was referring to this: https://github.com/openstack/neutron-lib/blob/master/doc/source/conventions.rst 17:33:04 "a long-term stable interface for subprojects" ? 17:33:04 we published it, not private, not legacy, so under our own rules: "Standard modules - current cycle + 2 deprecation policy" 17:33:23 admittedly i wrote that, and there's only three of us. but avoiding interface churn is why we exist. 17:34:53 But sometimes we land things in lib that are a copy of what was in Neutron, yet it should have been tweaked so that only some subset it public. 17:35:07 s/it/is/ 17:35:27 i expect we have some wiggle room if it hasn't hit pypi yet. did this? 17:37:20 unfortunately it appears to be in 0.2.0 17:37:28 dougwig; not sure I understand that statement. you are saying if the validators var didn’t get released as part of lib then we would have wiggle room? 17:38:26 if we released anything public (no underscore), and a release means it went on pypi, then we're stuck supporting it. if it's in master but hasn't been released, then we can likely tweak it. 17:39:12 why its confusing is because I thought we agreed “enhancements” to code moved into lib would be done “after the fact”… the statements sound a bit contradictory or at least cause some contention as now we only have a window of time to enhance code 17:39:44 you can move it into an _module.py or _module/*.py if you want to tweak it without it being public yet. 17:39:52 I do understand the premise, I’m just trying to understand how we manage “enhancing” code 17:39:58 boden: the "enhancements" must be done before the next pypi release 17:40:02 thats fair 17:40:59 so we have to follow our deprecation rule here I guess… or change our rules :) 17:41:37 "we haven't reached 1.0.0 yet, so we aren't stable" :) 17:41:39 yes, certainly releasing code as a library is a different kettle of fish than we're used to. 17:41:46 kevinbenton: lol 17:41:57 i see an 0.99.4567a in our future. 17:42:02 kevinbenton: tell that to the users 17:43:20 We should make a (devref?) note that we need look over new additions for potential enhancements before making any pypi release. 17:43:33 HenryG: agree 17:43:44 I had a doc change out there already so I can take that one 17:43:46 i wonder how hard it'd be to generate a 'new interfaces' report before release. 17:44:08 dougwig: that would be nice 17:44:14 +1 17:44:57 The other topic is about things like https://review.openstack.org/319769 17:46:09 It is not clear how many of those utils are used outside Neutron core 17:46:34 i believe you are referring to this comment? "This patch brings up an interesting question -- are these used anywhere but neutron? And if so, should we lib them, or does neutron itself have a place for its own "util" routines? I'm kind of torn." 17:46:46 yes 17:47:17 i'm a tad bit against supporting those interfaces in such a strict way if no one is using them except neutron. that seems to reduce flexibility for us as a project, not strengthen our external interface contracts. 17:47:29 it would be nice to have a tool to help with such analysis if one doesn’t already exist.. it’s time consuming to manually check each in a patch of this size 17:48:22 dougwig: I can certainly see that. But two things ... 17:49:49 1. Having a util non-private in Neutron means it could potentially be picked up externally at any point (or have we communicated that folks should not do that any more?) 17:50:20 2. External repos may have made a local copy of a Neutron util 17:51:24 the tox rule should prevent neutron imports, at least by official projects. 17:51:56 Right, I do think it makes sense to concentrate on the existing imports first. 17:52:41 I'll change my vote on the utils patch(es). 17:53:24 dougwig: sorry, which tox rule? 17:53:50 boden: hacking N530 17:54:00 'N530', 'neutron', 'neutron_lib.', logical_line, 17:54:00 message_override="direct neutron imports not allowed") 17:56:33 our arguments are way too tame. we need some yelling, chair throwing, etc... 17:57:04 just imagine henry in leather chaps, standing on the bar, holding a broken bottle. 17:57:25 yikes! ;) 17:57:37 Should I grow a beard? 17:57:54 "you will *not* change this interface!" "oh yes, i'm adding *kwargs* you m**f**!" 17:58:02 I agree with the agrument… I wasn’t aware of the future plans to enable N530 in projects 17:58:56 a general question - is there any way we can get more core eyes on lib patches? I won’t be able to complete the work we discussed for this release at the current rate. not complaining; just being transparent 18:00:22 you're right, we'll talk to armax. i've been distracted, though that is coming to an end. but we need more. too many and we'll start slipping more interfaces we're stuck with, though. 18:01:15 thx 18:02:09 anything else today? 18:02:22 The api-ref maybe 18:02:34 shoot 18:02:36 But I think Akihiro has that under control 18:03:37 Let's wait until he posts the api-ref verification sprint details. 18:04:07 ok 18:04:18 is that a virtual sprint? 18:04:38 I think we should probably make him core for those patches 18:04:47 When they start arriving 18:05:20 works for me. 18:06:08 Nothing else from me. 18:06:14 me either 18:07:09 ok, let's blast out of here. thanks all. 18:07:12 #endmeeting