18:00:17 <tbachman> #startmeeting networking_policy
18:00:18 <openstack> Meeting started Thu Jan 10 18:00:17 2019 UTC and is due to finish in 60 minutes.  The chair is tbachman. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:22 <openstack> The meeting name has been set to 'networking_policy'
18:00:39 <SridarK_> Hi All
18:00:44 <tbachman> SridarK_: hi!
18:00:52 <rkukura> hi
18:01:15 <tbachman> I’m not sure we have too much to cover today, but figured we’d meet, just in case
18:01:37 <tbachman> One thing we can discuss is the gate resources and branches
18:01:47 <tbachman> rkukura: SridarK_: any topics you all want to touch on?
18:02:05 <SridarK_> tbachman: not much from just coming up to speed
18:02:46 <rkukura> I can mention a bit about baked queries, for the record
18:02:53 <tbachman> sounds good
18:02:58 <tbachman> want to start off with that?
18:03:16 <rkukura> And also bring up the question of eliminating unmaintained code from the repo
18:03:23 <rkukura> sure
18:03:26 <tbachman> #topic Using baked queries
18:03:36 <tbachman> rkukura: you have the floor :)
18:03:38 <rkukura> So we have a patch in review that is specific to the AIM backend
18:04:11 <rkukura> #link https://review.openstack.org/#/c/623113/
18:04:44 <rkukura> This changes most of the queries in the various AIM drivers and extensions to use sqlalchemy’s baked query feature
18:05:20 <rkukura> this reduces the python CPU overhead in neutron-server by caching the generated queries rather than building them up each time they are executed
18:05:51 <rkukura> it makes the queries a bit more verbose, but I don’t think they are any more difficult to read or write once you are familiar with them
18:06:32 <tbachman> rkukura: do you have a sense of improvement this approach has, in terms of execution time?
18:06:40 <rkukura> I have covered all the AIM-specific queries in this patch (there are a few that can’t be baked in master, and more in older stable branches), but I have not touched any of the queries in GBP that are not AIM-specific
18:07:13 <rkukura> Just want to note that as a followup, the same approach could be applied to the non-AIM queries
18:07:29 <tbachman> ack
18:07:50 <rkukura> I see a noticible, but hard to quantifiy, improvement in the time needed to run the UTs, hopefully reducing timeouts in CI jobs
18:07:58 <tbachman> nice!
18:08:13 <tbachman> I’ll review the patch and backports today
18:08:21 <tbachman> I’d started it, but still have a bit to go
18:08:22 <rkukura> I also did some profiling of a UT that does some complex queiring, an measured about a 30% reduction in CPU usage for the UT itself.
18:08:33 <tbachman> that’s a good gain!
18:09:09 <rkukura> So that is probably >50% improvement in the query speed, since there is a lot of UT code that was also being profiled
18:09:42 <rkukura> It should be roughly equivalent to making the same exact query using raw SQL.
18:09:43 <tbachman> At some point, it might be interesting to share this kind of thing with the usptream neutron crew
18:09:50 <rkukura> right
18:10:24 <tbachman> SridarK_: if you get a chance, can you have a look at the patch and comment?
18:10:38 <rkukura> Unfortunately, older versions of sqlalchemy are lacking some features for the baked queries, so fewer queries are baked in the backports
18:10:39 <tbachman> rkukura: I’ll try to wrap up my review today
18:10:47 <SridarK_> tbachman: will do - started looking and trying to understand the changes
18:10:54 <tbachman> thx!
18:11:02 <rkukura> thanks SridarK_ and tbachman!
18:11:23 <tbachman> rkukura: anything else on that front?
18:11:40 <tbachman> If not, I’ll transition to the upstream gate topic
18:11:45 <rkukura> So I do not intend to followup with baking GPB or upstream neutron queries in the short term, but anyone is welcome to take those on
18:11:53 <tbachman> ack
18:12:56 <rkukura> that is for that
18:13:02 <rkukura> that’s it for that
18:13:04 <tbachman> k
18:13:08 <rkukura> can’t type
18:13:10 <tbachman> thx rkukura!
18:13:12 <tbachman> #topic EOL branches and upstream gate jobs
18:13:33 <tbachman> Although I haven’t seen this in the most recent gate jobs, we were seeing a lot of timeouts on the ocata branch
18:13:51 <tbachman> speculation was that zuul was limiting the amount of resources to ocata, as it was becoming EOL
18:14:05 <tbachman> We saw similar problems when the newton branch went EOL
18:15:00 <tbachman> Our “fix” for newton was to limit the UTs that run in the gate, with the understanding that people posting backports to newton had to run UTs locally without the tests being disabled
18:15:11 <rkukura> tbachman: do we know if these limits are in overall time, number of CPU cores, or both?
18:15:20 <tbachman> rkukura: I don’t, but will check
18:15:47 <rkukura> tbachman: that reminds me that we should do a local run of the full set of UTs in the stable/newton back-port of the baked_query patch
18:15:58 <tbachman> k
18:16:59 <tbachman> In any case, the most recent ocata jobs seem to be passing, so we may not have to make this change just yet, but I wanted to give folks a heads-up that we may have to use the same policy for that branch soon
18:17:08 <rkukura> is ocata a long term support branch for any distros we know of?
18:17:17 <tbachman> I think for Canonical it is
18:18:14 <tbachman> I’ll take the action to find out how these jobs are limited, and if/when ocata will become so-constrained
18:18:24 <tbachman> rkukura: SridarK_: any comments?
18:18:34 <SridarK_> tbachman: sounds good
18:19:10 <rkukura> tbachman: thanks!
18:19:23 <tbachman> rkukura: want to talk about the question of eliminating unmaintained code from the repo
18:19:25 <tbachman> ?
18:19:33 <rkukura> sure
18:19:37 <tbachman> #topic Unmaintained code in the GBP repo
18:20:19 <rkukura> I think we merged a patch a while back that turned off UTs for the servicechain feature in order to avoid CI timeouts
18:20:58 <rkukura> my understanding is that this code only worked with the old APIC policy driver, which has been eliminated since stable/ocata
18:21:53 <tbachman> rkukura: ack
18:21:59 <rkukura> so we should probably start some deprecation process to remove the code (functionality and UTs) from the repo if nobody plans to use it
18:22:20 <tbachman> rkukura: SridarK_: are you aware of how this is typically done upstream?
18:22:55 <SridarK_> tbachman: well usually there is a heads up for deprecation and if no one objects in a cycle or 2 we can remove it
18:23:07 <tbachman> Like something to the mailing list?
18:23:17 <SridarK_> tbachman: yes exactly
18:23:19 <tbachman> k
18:23:32 <rkukura> I’ve been giving heads up on this IRC channel for a while, but not sure if that counts ;)
18:23:52 <tbachman> heh
18:24:08 <tbachman> rkukura: SridarK_: would one of you be up for sending an email to the list?
18:24:31 <SridarK_> tbachman: surely no issues
18:24:37 <tbachman> SridarK_: thanks!
18:24:55 <rkukura> Maybe a patch to remove it, linked in the email
18:25:45 <tbachman> rkukura: would we need to leave the patch open beyond a release? Is there any issue in doing that?
18:25:46 <tbachman> (i.e. in order to account for giving at least one release cycle for deprecation)
18:26:08 <SridarK_> rkukura: i was thinking more of a heads up as the first step
18:26:15 <tbachman> I guess having such a patch is helpful b/c it is specific
18:26:17 <rkukura> lets start with an email
18:26:20 <tbachman> k
18:26:37 <rkukura> ideally we’d decorate stuff with deprecation warnings, but I really don’t think that is useful
18:26:48 <tbachman> any other comments on this topic?
18:27:00 <rkukura> nope
18:27:22 <SridarK_> nothing more from me
18:27:24 <tbachman> #topic Open Forum
18:27:38 <tbachman> Just want to welcome SridarK_ to the GBP channel!
18:27:47 <SridarK_> tbachman: thx :-)
18:28:27 <tbachman> SridarK_ is a new contributor to GBP — welcome SridarK_!
18:28:38 <tbachman> If there aren’t any other open items, I’ll wrap things up
18:28:59 <rkukura> nothing from me
18:29:06 <SridarK_> same here
18:29:07 <tbachman> k
18:29:10 <tbachman> Thanks all!
18:29:12 <tbachman> #endmeeting