18:01:41 <tbachman> #startmeeting networking_policy
18:01:42 <openstack> Meeting started Thu Aug  9 18:01:41 2018 UTC and is due to finish in 60 minutes.  The chair is tbachman. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:45 <openstack> The meeting name has been set to 'networking_policy'
18:01:51 <rkukura> Hi
18:01:52 <tbachman> #topic Agenda
18:02:20 <tbachman> I don’t really have one — but if anyone has topics that they want covered,  go ahead and shout them out
18:03:47 <rkukura> If annakk were here, I’d suggest updating her on the queens support work
18:04:15 <tbachman> ack
18:04:20 * tbachman peeks around fo annakk
18:06:58 <SumitNaiksatam> tbachman: the issue that kent is seeing might be related to neutron UT setup (perhaps changed in queens)
18:07:17 <tbachman> SumitNaiksatam: that’s a good topic :)
18:07:32 <tbachman> #topic queens branch
18:07:49 <tbachman> We’re workng on adding queens to our stable/branches
18:08:20 <tbachman> #link https://review.openstack.org/#/c/581911/ <== current queens WIP patch
18:08:33 <rkukura> more precisely, towards basing our master on neutron’s stable/queens instead of stable/pike
18:08:47 <tbachman> rkukura: thx!
18:09:05 <tbachman> actually both, right?
18:09:19 <tbachman> SumitNaiksatam mentioned that some of the UT failures might be related to the neutron UT setup, which may have changed in queens
18:09:25 <tbachman> SumitNaiksatam: do you have additional insight on that?
18:10:20 <SumitNaiksatam> tbachman: not really, thats my conspiracy theory for now :-)
18:10:25 <tbachman> heh
18:10:39 <SumitNaiksatam> was discussing with kent a couple of days back, and looked at it briefly
18:10:43 <tbachman> If it’s true, then it’s just a conspiracy ;)
18:11:14 <SumitNaiksatam> tbachman: and we have had a long history of those :-P
18:11:22 <tbachman> lol
18:11:45 <SumitNaiksatam> i couldnt nail it down, but the stack trace seemed to suggest that to me
18:11:53 <tbachman> I know that some of the UT failures seemed to suggest that API calls were being made more than once
18:12:04 <tbachman> or somehow became recursive
18:12:07 <SumitNaiksatam> it doesnt seem like its hitting any of our code where it fails
18:12:43 <SumitNaiksatam> yeah, moreover that recursive thingy is with regards to neutron resources
18:12:57 <tbachman> interesting
18:13:12 <SumitNaiksatam> pecan.middleware.recursive.RecursionLoop: Forwarding loop detected; '/error/404' visited twice (internal redirect path: [u'/networks/943de9b6-6136-4f22-8f86-9324ac0b0074.json', '/error/404'])
18:13:31 <SumitNaiksatam> i have never seen this error before
18:14:40 <tbachman> I think in queens they moved to the pecan middleware?
18:15:36 <tbachman> oh
18:15:43 <tbachman> this is in the test code — not even our plugin
18:15:45 <tbachman> i see
18:16:04 <tbachman> Did we do any special wrapping of the requests?
18:16:12 <tbachman> for UTs?
18:16:34 <SumitNaiksatam> nothing that comes to me immediately
18:17:00 <SumitNaiksatam> we might have inadvertantly done something and that might have come into play with the move to pecan
18:17:10 <SumitNaiksatam> i think the pecan migration was ongoing for a long time
18:17:14 <SumitNaiksatam> https://github.com/jimrollenhagen/pecan/blame/master/pecan/middleware/recursive.py
18:17:40 <SumitNaiksatam> actually #link https://github.com/jimrollenhagen/pecan/blame/master/pecan/middleware/recursive.py#L28-L30
18:17:45 <SumitNaiksatam> it seems to have been there for a while
18:18:14 <SumitNaiksatam> so i dont think its a change in pecan
18:18:46 <tbachman> annakk just emailed — I guess she’s having trouble joining. I think it’s probably b/c of the registered NIC requirement that the infra folks imposed to deal with all the spam on IRC
18:19:16 <SumitNaiksatam> tbachman: good point, i noticed her email too, but it didnt strike me that would have been the issue
18:19:24 <SumitNaiksatam> good catch
18:20:00 <rkukura> Did queens change the default to pecan? Have we ever tested using pecan with earlier releases?
18:20:03 <SumitNaiksatam> i think rkukura might be more familiar with the changes to the neutron UT setup
18:20:27 <rkukura> I’ve only been looking at neutron branches supported by gbp!
18:20:28 <SumitNaiksatam> rkukura: my understanding was that the change was incrementally happening
18:20:34 <SumitNaiksatam> has been happening
18:21:13 <SumitNaiksatam> now if you ask me what that incremental path was, i wont be able to tell, but pecan was definitely in plan in pike too
18:21:18 <tbachman> I thought there was a switchover in neutron for queens tho
18:21:21 <SumitNaiksatam> plan -> play
18:21:23 <tbachman> meaning the servers were switch
18:21:25 <tbachman> switched
18:21:33 <tbachman> the code was there before, but you had to configure to select it
18:21:38 <tbachman> but I think in queens it’s the defaulit
18:21:44 <rkukura> I’d think pecan support would have been usable for at least a cycle before becoming the default
18:21:54 <SumitNaiksatam> tbachman: okay, that might be the case
18:22:40 <SumitNaiksatam> also, i think pecan libraries were being used earlier (which is what i might be recalling having hit before)
18:22:53 <SumitNaiksatam> anyway
18:23:16 <tbachman> https://github.com/openstack/neutron/blob/stable/queens/neutron/api/v2/router.py
18:23:24 <SumitNaiksatam> annakk: hi
18:23:28 <tbachman> https://github.com/openstack/neutron/commit/db1058a499353149a9e57d8c1d7e8e64b30772f9#diff-b9672caf8662b545dab77591f4fa326c
18:23:33 <tbachman> hi annakk!
18:23:36 <annakk> hi!
18:23:41 <rkukura> hi annakk!
18:23:52 <annakk> sorry took me some time to figure out the verification
18:24:15 <tbachman> #link https://github.com/openstack/neutron/commit/db1058a499353149a9e57d8c1d7e8e64b30772f9#diff-b9672caf8662b545dab77591f4fa326c <= switch to pecan for UTs
18:24:19 <SumitNaiksatam> tbachman: good find
18:24:21 <tbachman> that was in queens, I believe
18:24:38 <tbachman> I’d stumbled upon this before, but I can’t recall why
18:24:49 <tbachman> that’s how I usually find things :P
18:25:04 <SumitNaiksatam> :-)
18:25:32 <tbachman> annakk: just to catch you up — we’re discussing a WIP patch for adding stable/queens, and moving master to queens
18:26:00 <tbachman> Here’s the patch (already linked for IRC, so won’t re-link again): https://review.openstack.org/#/c/581911/
18:26:05 <annakk> yes thanks for the update
18:26:09 <tbachman> np!
18:26:18 <SumitNaiksatam> this switch should have been ideally transparent to us
18:26:20 <tbachman> We were just discussing some of the UT failures
18:26:22 <tbachman> SumitNaiksatam: ack
18:26:42 <SumitNaiksatam> but perhaps we are using some aspect of the old APIRouter (or using incorrectly)
18:26:44 <SumitNaiksatam> thinking loud
18:28:03 <rkukura> is it possible that our gbp REST API methods calling neutron’s REST API is being detected as recursion?
18:28:30 <rkukura> I’ll admit I haven’t looked closely at recent versions of the WIP patch, or at the failures
18:28:51 <tbachman> rkukura: I was wondering the same
18:29:20 <tbachman> since we have that extra layer that was in place in case GBP ever became an endpoint
18:30:27 <tbachman> I guess we’ll dive into this some more with the patch
18:30:33 <tbachman> annakk: anything you wanted to discuss?
18:30:38 <tbachman> it’s been some time since we met
18:31:08 <rkukura> we should probably also mention recent changes to the core team
18:31:50 <tbachman> rkukura: yes, although I don’t know if we’ve spoken directly with them about this?
18:31:51 <SumitNaiksatam> rkukura: thats a good theory
18:32:03 <SumitNaiksatam> but i dont think we go through the API layer for those calls
18:32:31 <annakk> not really
18:33:36 <rkukura> don’t recall if we call the plugin methods directly, or go through some neutron code
18:33:57 <SumitNaiksatam> #link https://github.com/openstack/group-based-policy/blob/master/gbpservice/network/neutronv2/local_api.py#L288
18:34:21 <SumitNaiksatam> i might be forgetting things here, but i think that is a direct call on the plugin reference
18:35:08 <rkukura> SumitNaiksatam: That does look pretty direct
18:35:47 <tbachman> so, maybe not the change to pecan then
18:36:03 <tbachman> or at least not in-and-of-itself
18:36:08 <tbachman> secondary effect somehoe
18:36:11 <tbachman> somehow
18:37:01 <SumitNaiksatam> rkukura: but i have to say again, thats a really smart theory! (given that the message says “twice”) :-)
18:37:12 <tbachman> I guess we should move on
18:37:24 <tbachman> #topic Team Cores
18:37:37 <tbachman> To address rkukura’s comment directly: two cores — who are also people from our team — have recently moved on: Ivar Lazarro and Amit Bose. I don’t believe that they are going to continue participating in GBP, but we do have to follow up with them to confirm.
18:38:25 <tbachman> SumitNaiksatam: annakk: rkukura: putting out there whether or not we should consider adding cores to GBP
18:38:49 <SumitNaiksatam> i would proposing adding Kent Wu
18:38:57 <rkukura> +2
18:39:02 <SumitNaiksatam> i think rkukura also suggested this before
18:39:06 <annakk> +2
18:39:09 <tbachman> +2
18:39:11 <tbachman> okay
18:39:28 <tbachman> I’m not sure if there’s an official process here for adding cores
18:39:31 <SumitNaiksatam> kent has been pretty active
18:39:35 <tbachman> ack
18:39:38 <SumitNaiksatam> (although more on the driver side)
18:39:53 <rkukura> I think the queens patch qualifies him!
18:39:53 <SumitNaiksatam> but having worked with him, i know he understands the code base
18:40:04 <SumitNaiksatam> rkukura: ah good point!
18:42:47 <tbachman> I was trying to look him up on stackalytics, but resulted in a #fail
18:43:05 <tbachman> I think it doesn’t cover GBP
18:43:48 <tbachman> #6 on our committer list
18:43:48 <SumitNaiksatam> we had it in the past, but not sure if it was dropped at some point
18:44:04 <SumitNaiksatam> anyway, i think we are all in agreement :-)
18:44:11 <tbachman> #link https://github.com/openstack/group-based-policy/graphs/contributors <= GBP contributors list
18:44:30 <tbachman> #link https://github.com/openstack/group-based-policy/commits?author=kentwu1 <= Kent Wu’s commits in GBP
18:44:39 <SumitNaiksatam> thanks to ivar and amit for their fantastic contributions
18:44:40 <tbachman> SumitNaiksatam: ack
18:44:44 <tbachman> SumitNaiksatam: ack again
18:45:25 <tbachman> Do we need to do something like pound-startvote?
18:45:27 <tbachman> to make it official?
18:45:45 <SumitNaiksatam> tbachman: probably not
18:45:49 <tbachman> k
18:45:53 <tbachman> Alright
18:46:05 <SumitNaiksatam> tbachman: you can just add him to the team group-based-policy team
18:46:11 <tbachman> SumitNaiksatam: will do!
18:46:21 <tbachman> Unless there’s something I’m missing, we’ve just elected Kent Wu as a core in GBP
18:46:25 <tbachman> Congratulations Kent!
18:46:53 <tbachman> rkukura: annakk: SumitNaiksatam: anything else?
18:47:20 <rkukura> hopefullly Kent  will start attending these (monthly)  meetings
18:47:22 <annakk> since we're mentioning gratitudes, I wanted to thank Sumit for all his efforts
18:47:33 <tbachman> annakk: +1k!
18:47:49 <SumitNaiksatam> annakk: thanks annakk :-)
18:47:54 <SumitNaiksatam> and tbachman
18:48:02 <tbachman> thanks SumitNaiksatam!
18:48:17 <SumitNaiksatam> rkukura has been an equal partner in crime from the beginning
18:48:19 <annakk> a really big thanks for being patient with all my questions
18:48:40 <tbachman> annakk: thanks for all your questions, and contributions :)
18:48:41 <SumitNaiksatam> annakk: that was nothing, dont worry
18:48:48 <annakk> :)
18:48:49 <SumitNaiksatam> tbachman: +1
18:49:10 <tbachman> If there’s nothing else, then I’ll close the meeting
18:49:26 <SumitNaiksatam> nothing from me for today!
18:49:30 <SumitNaiksatam> tbachman: thanks!
18:49:33 <annakk> nor from me
18:49:37 <tbachman> SumitNaiksatam: np!
18:50:01 <rkukura> thanks everyone!
18:50:03 <tbachman> #endmeeting