14:00:11 <lujinluo> #startmeeting neutron_upgrades
14:00:19 <openstack> Meeting started Thu May 10 14:00:11 2018 UTC and is due to finish in 60 minutes.  The chair is lujinluo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to 'neutron_upgrades'
14:00:33 <lujinluo> hello everyone!
14:00:42 <mlavalle> o/
14:00:47 <TuanVu> Hi Luo
14:00:53 <TuanVu> Hi mlavalle
14:00:55 <ihar> o/
14:00:58 <lujinluo> o/
14:01:02 <TuanVu> Hi Ihar
14:01:44 <lujinluo> We do not have any action items from last meeting
14:01:57 * mlavalle is multitasking in two meetings today. Could be slow to respond ;-)
14:02:15 <lujinluo> but last week we have these two patches merged: https://review.openstack.org/#/c/553617/ and https://review.openstack.org/#/c/563736/
14:02:43 <lujinluo> Now ovo can automatically detect which engine facade to use! thanks ihar ! \o/
14:02:51 <ihar> no one reverted any of them right?
14:02:56 <ihar> I may have missed :)
14:03:10 <lujinluo> as far as i spied, no :)
14:04:08 <TuanVu> yeah, it's great that finally Ihar's 2 patches got merged :D
14:04:20 <lujinluo> #topic OVO
14:04:31 <lujinluo> https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db+(status:open)
14:04:52 <lujinluo> https://review.openstack.org/#/c/549168/ the first one is still pretty red
14:05:18 <lujinluo> hungpv_: do you have any updates you want to share with us about https://review.openstack.org/#/c/549168/ ?
14:06:43 <hungpv_> Hi, not really at this moment. I'm trying a new solution for this.
14:06:53 <hungpv_> Will update on Gerrit
14:07:03 <lujinluo> ok. then next one
14:07:19 <lujinluo> https://review.openstack.org/#/c/565773/ tag ovo
14:07:37 <lujinluo> i went through this one this afternoon
14:07:49 <lujinluo> it only moves db queries to ovo file
14:08:00 <lujinluo> which is not what we eventually want
14:08:28 <ihar> yeah as always, we want the OVO boundary to not talk in sqlalchemy-speak
14:09:20 <lujinluo> yes, i will leave a comment to suggest him/her not to simply move db queries
14:09:21 <ihar> that should probably be some kind of code inside base.py that would handle extra filter (tags) accordingly
14:09:28 <ihar> for all objects that have tags
14:10:03 <lujinluo> agree
14:14:10 <ihar> is it just me, or no one is talking? :)
14:14:27 <njohnston> Not just you :-)
14:14:46 <mlavalle> not just you
14:14:49 <mlavalle> LOL
14:15:15 <TuanVu> can we move on to the next patch?
14:15:18 <lujinluo> not just you, sorry i was typing the comment in gerrit
14:15:39 <TuanVu> oh, ok then :)
14:15:41 <lujinluo> ok next two patches are in an effort to solve the constant db queries in network ovo patches
14:15:58 <TuanVu> yeah
14:16:11 <lujinluo> https://review.openstack.org/#/c/565358/ this one is not to fetch none listed ovo objects
14:16:31 <TuanVu> thanks for the great help from Ihar, the problem with duplicated queries for "networksecuritybindings" and "externalnetworks" has been solved :)
14:16:34 <lujinluo> and it then breaks portbindinglevel test, which is addressed by https://review.openstack.org/#/c/566750/
14:16:46 <ihar> yeah. this one has an issue with segment returned as None to agents
14:17:07 <lujinluo> ihar: for the latter, i hard-coded segment creation in test_base.py
14:17:10 <ihar> it doesn't really break anything. the issue with the test you mentioned is that it's not really executed
14:17:40 <lujinluo> oh yeah
14:17:41 <ihar> the other patch attempts to enable the test, then I can add a unit test on top that would validate (and help to fix) the None-segment issue
14:18:02 <ihar> the only place the segment issue is popping up currently is tempest and that's not the best environment to debug
14:18:33 <ihar> so there is more work to do in regards to the none-fields patch
14:19:16 <ihar> and of course I don't have a lot of time to invest in the project and will get to it on Monday only. so if some can shake the patches to merge before I reach there that would be great.
14:20:28 <lujinluo> much well explained than i could, haha.
14:21:39 <lujinluo> anyway, i wrote some ugly codes in the portbindinglevel one and will try to refactor it. Then I will help with the none-fields patch and i think it would be better if TuanVu could work on it with me too
14:22:12 <lujinluo> since we need network ovo patch to validate the none-fields patch
14:22:17 <TuanVu> I'll try my best :)
14:22:43 <TuanVu> thank you in advance, Luo
14:23:16 <ihar> lujinluo: but the test patch seems to pass zuul with your latest upload
14:23:24 <ihar> meaning it could use some reviews?
14:23:59 <lujinluo> ihar: yeah, but the codes are really ugly, haha
14:24:34 <ihar> ok gotcha I will need to check
14:24:42 <lujinluo> thanks
14:25:03 <ihar> oh I see what you did there. yeah we need to improve it. but that's a good start
14:25:14 <lujinluo> then TuanVu and i will see how we can revise the non-field patch. if we make any process, we will send you updates
14:25:28 <ihar> maybe base test class need hooking mechanism to allow subclasses to do this kind of object injection into the failing test case
14:25:39 <ihar> lujinluo: thanks!
14:25:49 <lujinluo> :-) thank you!
14:26:16 <lujinluo> https://review.openstack.org/#/c/507772/ next is the network ovo patch, that we have discussed a little bit
14:26:27 <lujinluo> it is blocked by the two patches mentioned earlier
14:26:56 <lujinluo> TuanVu: besides the constant queried issue, do you have anything else that is not clear?
14:27:05 <TuanVu> yeah, but at least the problem with duplicated queries for "networksecuritybindings" and "externalnetworks" has been solved
14:27:25 <TuanVu> At this moment, there's only 1 remaining failed unit test due to duplicated query for RBAC:
14:27:26 <TuanVu> "neutron.tests.unit.objects.test_network.NetworkDbObjectTestCase.test_get_objects_queries_constant"
14:27:57 <TuanVu> other than this failing test case, I have no other concern yet
14:28:11 <ihar> yeah but what's the plan with rbac
14:28:57 <TuanVu> honestly, I haven't had any plan yet
14:29:15 <TuanVu> because I haven't figured out how to handle "shared"
14:30:09 <ihar> there is a rbac metaclass that wraps around objects like network that should help with that
14:30:16 <TuanVu> as you see, Ihar, duplicated query issue for RBAC is raised when _load_shared is triggered
14:31:01 <TuanVu> thanks for your suggestion, Ihar. Could you please explain more?
14:31:01 <ihar> right. somewhere down the _load_shared path rbac entries are fetched not from the model you already have but fetched again
14:31:36 <ihar> I would imagine that whatever is returned from neutron/objects/db/api.py should be a model with rbac_entries pre-fetched
14:32:25 <ihar> I don't have details about how the rbac metaclass works on me (that was a long time ago) but that's a bird eye view
14:33:02 <ihar> the fact that you don't pass fetched model into _load_shared may be relevant
14:34:01 <TuanVu> thanks, could you please explain more about "passing fetched model"?
14:34:48 <TuanVu> btw, I'll check more about rbac metaclass as your suggestion
14:36:17 <ihar> base get_object[s] always calls to neutron/objects/db/api.py that fetches the sqlalchemy model and returns it to the base class that then converts it to object fields, and also stores it as self.db_obj. the rbac entries required to determine if the network is shared or not should be already present on the said model.
14:36:45 <ihar> the fact that you see redundant sql statements probably means that while we already have the rbac entries on the model, they are not used when calculating shared state
14:37:07 <ihar> which suggests to me that the model is not used (or not used properly) somewhere deep in _load_shared implementation
14:37:41 <ihar> I think it would help to first determine which exact code triggers the redundant statements
14:37:53 <ihar> and then figure out how to rewrite it to reuse the self.db_obj model
14:38:43 <TuanVu> yeah, I see
14:39:03 <TuanVu> here's the code which triggers the redundant statements
14:39:08 <TuanVu> https://review.openstack.org/#/c/507772/46/neutron/objects/network.py@289
14:40:04 <TuanVu> based on your suggestion, I think I'll need to rewrite my _load_shared function
14:40:05 <ihar> yeah but that's just top of the stack.
14:40:21 <ihar> it may be that the get_shared_with_tenant needs some tweaks
14:41:10 <TuanVu> hmm ... yeah, I'll dig deeper
14:43:38 <lujinluo> ok
14:44:18 <lujinluo> let's move to the next one then
14:44:28 <lujinluo> https://review.openstack.org/#/c/544206/ port binding ovo which is by me
14:44:34 <TuanVu> thank you very much, Ihar. Your suggestions do help a lot!
14:45:09 <lujinluo> i promised Miguel to rebase it upon his patch, but i did not have enough time to fix all the failed UTs in my local environment
14:45:31 <lujinluo> I will respin it hopefully before next meeting
14:45:35 <ihar> lujinluo: you can always push a wip version :)
14:45:46 <ihar> if nothing else for backup
14:46:07 <lujinluo> ihar: nice suggestion. we love red anyway, \o/
14:46:16 * ihar never leaves a patch on local environment. what if tomorrow a volcano errupts under my chair?
14:46:36 <lujinluo> well, i have to say, this could possibly happen in Japan
14:46:40 <TuanVu> good point, Ihar, haha
14:46:42 <ihar> hahaha
14:46:59 <TuanVu> +1, Luo, haha
14:47:10 <ihar> here too. maybe not volcano but I am sitting right now right above the Hayward fault.
14:47:58 <lujinluo> ahh, a lot of earthquakes?
14:48:23 <ihar> nah it's nothing compared to Japan
14:48:32 <ihar> though I admit it's quite a lot for where I came from!
14:48:46 <ihar> we had like 3 in the last year
14:48:58 <ihar> I didn't have a single one back in Europe in my whole life
14:49:19 <lujinluo> haha
14:49:34 <ihar> anyhoo... :)
14:49:43 <mlavalle> Growing up in Mexico City, you get used to 2 or 3 erathquakes every year
14:49:45 <lujinluo> back to ovo..
14:49:52 <TuanVu> I feel so lucky because of living in a country without volcano or earth quake now
14:49:57 <mlavalle> and the ocassional big one
14:50:12 <lujinluo> ok back to earthquakes again..
14:50:22 <lujinluo> we have 2 - 3 like per month, i guess?
14:50:23 <TuanVu> haha
14:50:56 <ihar> :))) lujinluo wow. you probably don't even mind an occasional 5-6 one right? :)
14:51:31 <lujinluo> the latest national wide alert was about a volcano eruption 3 weeks ago
14:52:00 <ihar> the price of the beatiful Japanese hills and mountains I guess
14:52:18 <lujinluo> i think the first thing i will do tmr morning would be pushing the wip patch to gerrit
14:52:35 <ihar> ok great. any more ovo stuff in the queue?
14:52:51 <lujinluo> no, the rest are not touched since last week
14:53:02 <lujinluo> #topic open discussion
14:53:07 <TuanVu> there's OVO for Segments and Service Type
14:53:21 <TuanVu> but I'll continue working on them after OVO for Network patch
14:53:44 <mlavalle> Just wanted to mention that IMO, https://review.openstack.org/#/c/414251 is good now for next round of reviews
14:54:10 <lujinluo> cool, let's tackle them down one by one!
14:54:28 <mlavalle> and I have a series of smaller (bite size) patches that depend on it https://review.openstack.org/#/q/topic:bp/live-migration-portbinding+(status:open+OR+status:merged)
14:54:29 <ihar> mlavalle: ack
14:54:46 <mlavalle> that series completes the implementation of multiple port binding
14:54:54 <ihar> mlavalle: do you have tempest patches for the feature?
14:55:06 <mlavalle> ihar: that's the next step
14:55:35 <lujinluo> mlavalle: ack.
14:56:27 <ihar> mlavalle: ok it would be nice to have these before we merge. what d'you think?
14:56:56 <mlavalle> ihar: mhhh I would like to merge to make it easier for the NOva guys to test their code
14:57:15 <mlavalle> otherwise we are rebasing all the time
14:57:30 <ihar> mlavalle: ack
14:57:45 <mlavalle> ihar: I won't forget the Tempest testing. I promise
14:57:55 <mlavalle> it is really the very next step
14:58:29 <ihar> ok I will review it first thing when I get time for openstack
14:58:58 <mlavalle> :-)
14:59:21 <lujinluo> ok! we have 2 more mins left for anyone who has anything else to share
14:59:34 <lujinluo> if not, then we can close it for today!
14:59:42 <mlavalle> o/
14:59:50 <lujinluo> #endmeeting