14:01:27 <ihrachys> #startmeeting neutron_upgrades
14:01:29 <openstack> Meeting started Thu Nov 16 14:01:27 2017 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:32 <annp> hi
14:01:33 <openstack> The meeting name has been set to 'neutron_upgrades'
14:01:39 <lujinluo> o/
14:01:45 <TuanVu> Hi everybody
14:01:56 <ihrachys> hi annp TuanVu lujinluo
14:02:13 <hungpv> Hi guys
14:02:18 <ihrachys> hungpv, hey!
14:02:20 <TuanVu> Hi Ihar
14:02:39 <ihrachys> let me start by saying I am very sorry the previous meeting didn't happen because I screwed up time zones (seems like there was summer time shift)
14:02:58 <TuanVu> no problem, Ihar
14:03:07 <lujinluo> So it is 6am for you now? ihrachys
14:03:23 <hungpv> Hi ỉhachys, that's fine
14:03:32 <ihrachys> yeah. which is fine, but I didn't expect that the prev week and slept like a baby :)
14:03:36 <annp> no problem,
14:04:08 <lujinluo> LOL, i see..
14:04:41 <ihrachys> afair summer time shift is in different times in different locations, not sure if you had yours (if you do), so be ware
14:05:10 <lujinluo> we do not have time shifts in Japan. I am all safe, ;)
14:05:39 <annp> me too in vietnam :)
14:05:47 <TuanVu> yeah, same here
14:05:49 <ihrachys> that's cool. smart people are smart.
14:06:17 <ihrachys> in my country, they didn't do it either. that's some 19th century bs :)
14:06:30 <ihrachys> anyway :)
14:06:31 <ihrachys> #topic OVO
14:06:48 <ihrachys> before we dive in, I'd like to update about what happened with subnet ovo patch
14:07:00 <ihrachys> we merged it but then it was reverted because it broke midonet
14:07:22 <ihrachys> the breakage was https://launchpad.net/bugs/1731623
14:07:22 <openstack> Launchpad bug 1731623 in networking-midonet "many UT cases are broken due to "AttributeError: type object 'Route' has no attribute 'foreign_keys'"" [Critical,New]
14:07:59 <ihrachys> slaweq root caused it and found out that it happened because both neutron and os-vif register an object with the same name (Route) in OVO registry
14:08:35 <ihrachys> and apparently then neutron makes an attempt to serialize a Subnet using os-vif Routes
14:08:38 <ihrachys> which of course fails
14:09:06 <ihrachys> slaweq reported this bug to fix that: https://bugs.launchpad.net/neutron/+bug/1731948
14:09:06 <openstack> Launchpad bug 1731948 in neutron "Wrong OVO classes registered in some cases" [Medium,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:09:18 <ihrachys> and there is a patch already up for review: https://review.openstack.org/519622
14:09:34 <ihrachys> the idea is creating a OVO registry just for neutron objects
14:09:57 <ihrachys> this is the gist of the change: https://review.openstack.org/#/c/519622/4/neutron/objects/base.py
14:10:15 <ihrachys> it's a bit hacky, and I would like to check with oslo folks whether there is a better way before merging
14:10:29 <ihrachys> but nevertheless it seems that it fixes the issue for midonet
14:11:27 <ihrachys> slaweq proposed a revert for subnet revert here: https://review.openstack.org/#/c/519762/2 that's on top of the patch introducing the new registry
14:12:29 <ihrachys> sounds good?
14:12:42 <lujinluo> yes
14:12:51 <TuanVu> thanks for the summary, Ihar
14:12:56 <lujinluo> i was slowly digesting all the info..
14:13:29 <ihrachys> cool!
14:13:47 <ihrachys> now to other patches up for review
14:13:49 <ihrachys> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db
14:14:06 <ihrachys> (btw we landed some l3 agent patches too)
14:15:00 <ihrachys> first being https://review.openstack.org/#/c/407868/ "[DNR] Integration of (Distributed) Port Binding OVO"
14:15:19 <lujinluo> i am slowly debugging this one
14:15:30 <lujinluo> also i did not expect gary reviewed it, omg
14:15:42 <lujinluo> i even put DNR there..
14:16:18 <ihrachys> DNR is probably not a common tag
14:16:30 <ihrachys> we usually use WIP for work in progress and DNM for never merge
14:16:38 <lujinluo> oops.. my bad
14:17:12 <ihrachys> is it the patch where you needed to set up dvr env locally to debug it?
14:17:23 <lujinluo> yes, exactly
14:17:41 <lujinluo> also the devstack env breaks easily when running tempest
14:17:54 <lujinluo> not sure why. but it does slow down my progress a bit
14:18:01 <ihrachys> what do you mean
14:18:34 <lujinluo> so i use $ testr run to run specific tempest test
14:18:55 <lujinluo> but after some attempts, keystone breaks and i cannot get authentication
14:19:26 <lujinluo> then i rebuilt another devstack..
14:19:30 <ihrachys> I see. I am not aware of that.
14:19:49 <ihrachys> lujinluo, that sucks. do you use a VM? then maybe snapshots will help.
14:20:00 <lujinluo> yes, i use VM
14:20:08 <ihrachys> at least you save the time of ./stack.sh
14:20:13 <lujinluo> i will snapshot the current working one tmr
14:20:43 <ihrachys> just make sure that you evacuate work in progress code though before restoring a previous snapshot. :)
14:21:06 <lujinluo> ah, right. thanks for the heads up
14:21:12 <ihrachys> ok next patch is https://review.openstack.org/#/c/396351/ "Integration of Floating IP OVO"
14:22:10 <lujinluo> Slawek commented whether we can use ovo methods directly in two places
14:22:52 <lujinluo> https://review.openstack.org/#/c/396351/43/neutron/db/l3_db.py line 1448 and 1520
14:23:30 <lujinluo> i think we can let 1448 go, but not 1520
14:24:15 <ihrachys> agreed. though dragonflow shouldn't have used the method
14:24:45 <lujinluo> then while i was deleting 1448, i met a problem
14:25:51 <lujinluo> i also need to replace self.db._floating_ip_exists with ovo_exist() in https://review.openstack.org/#/c/396351/43/neutron/tests/unit/db/test_l3_db.py@210
14:26:25 <lujinluo> but then other UTs are failing because l3_obj.FloatingIP.objects_exist() remains to be true
14:27:01 <lujinluo> I am confused why l3_obj.FloatingIP.objects_exist() is not cleared at the end of line 212
14:28:08 <lujinluo> failing UTs http://logs.openstack.org/51/396351/42/check/openstack-tox-py27/7a25632/testr_results.html.gz
14:28:16 <ihrachys> lujinluo, you modify real class attribute (which is a method)
14:28:25 <ihrachys> it won't restore back after execution
14:28:31 <ihrachys> so instead you should use mock.patch
14:28:42 <lujinluo> Shall I manually clear it at line 212?
14:28:48 <lujinluo> or is there any better way
14:28:52 <ihrachys> with mock.patch.object(self.db, '_floating_ip_exists'):
14:29:04 <lujinluo> Thanks!
14:29:06 <ihrachys> no, setting it is unsafe in the first place
14:29:20 <ihrachys> because if your test case later fails you may not restore it
14:29:47 <lujinluo> I see.
14:30:58 <ihrachys> next is https://review.openstack.org/#/c/507772/ "Use Network OVO in db_base_plugin"
14:30:58 <lujinluo> I will modify the codes accordingly.
14:31:16 <TuanVu> this patch is still pending because of the bug mentioned by Slawek
14:31:26 <TuanVu> we're still working on it
14:31:42 <ihrachys> TuanVu, right. but you can already rebase the patch on top of slaweq's, that should unblock you
14:32:05 <TuanVu> thank you Ihar, yes, I will
14:32:39 <ihrachys> next is https://review.openstack.org/#/c/506037/ "Part II of Integrate Port OVO"
14:32:54 <ihrachys> that one is rather red
14:33:02 <ihrachys> and needs a rebase
14:33:16 <lujinluo> yes, will rebase it
14:33:24 <ihrachys> does it depend on bindings patch somehow?
14:34:19 <lujinluo> No, I do not plan to touch plugin/ml2/plugin.py in this patch
14:34:31 <lujinluo> then it does not depend on portbinding
14:35:07 <ihrachys> ok
14:35:24 <ihrachys> then we have https://review.openstack.org/#/c/516961/ "Router to OVO"
14:35:52 <ihrachys> seems like I am slow to review that one. I'll make it a priority for today
14:36:11 <hungpv> Yes. Please have a look at it
14:36:34 <hungpv> In the meantime I'm developing patches for integration
14:36:47 <ihrachys> yeah was about to ask :)
14:36:59 <hungpv> Hopefully can be ready for review next week
14:37:01 <ihrachys> ok seems like router is in good hands
14:37:21 <ihrachys> note that you can probably reuse a lot of code from https://review.openstack.org/421863
14:38:08 <hungpv> Thank you, I'll surely look at it
14:38:13 <lujinluo> ;) help yourself
14:39:44 <ihrachys> seems like we have fewer objects in the works right now, let's have a look at the list of direct imports of models
14:40:41 <ihrachys> list of those imports in tree: https://da.gd/QXnD
14:41:29 <ihrachys> there are some model definitions in the list, f.e. neutron/db/port_security/models.py
14:41:32 <ihrachys> those are red herrings
14:41:43 <ihrachys> (should probably eventually move under neutron/db/models
14:42:46 <ihrachys> some of them may actually be needed / hard to remove either
14:43:08 <lujinluo> yeah, need to take a closer look
14:43:22 <ihrachys> f.e. I see cases where we use models to expunge objects from session; that you can't do with OVO (though maybe we should think about how to expose it without revealing models)
14:44:14 <lujinluo> exactly. I tried .update() but seems to be problematic
14:44:14 <ihrachys> I am going to prepare a full classified list of remaining imports for the next meeting, then we can assess what's really missing
14:44:43 <lujinluo> i think we also lack of ways to deal with joins between multiple models
14:45:46 <ihrachys> yeah that one is tough. so far we were just moving the code under neutron/objects/... since at least we isolate models code in a single place. but ideally we would have some generic mechanism. not sure what it could be. if you have ideas, please share.
14:47:31 <lujinluo> yeah
14:48:12 <lujinluo> i do not have a good idea for now though, let's just keep that in mind first
14:48:14 <ihrachys> #action ihrachys to categorize remaining models imports
14:49:56 <ihrachys> #topic Open discussion
14:50:00 <ihrachys> anything else to cover?
14:50:11 <lujinluo> none from me.
14:50:15 <TuanVu> me either
14:51:38 <hungpv> nothing from me
14:51:44 <ihrachys> cool, thanks for joining
14:51:52 <lujinluo> thanks!
14:51:55 <ihrachys> #endmeeting