14:00:18 <lujinluo> #startmeeting neutron_upgrades
14:00:19 <openstack> Meeting started Thu Jun 28 14:00:18 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:23 <openstack> The meeting name has been set to 'neutron_upgrades'
14:00:34 <lujinluo> Hi all! Long time no see
14:01:23 <TuanVu> Hi Luo :D
14:01:23 <TuanVu> great to see you
14:01:25 <njohnston> Welcome back!
14:01:38 <lujinluo> Thanks njohnston for taking over the duties for the past two weeks
14:01:47 <njohnston> I am happy to have been of service.
14:02:06 <lujinluo> I read the logs of the past two meetings, it seems we have some AIs? njohnston
14:02:51 <njohnston> Yes, 1 moment
14:02:59 <njohnston> (I have to look them up)
14:03:08 <lujinluo> sure
14:04:48 <njohnston> So first one was to get core reviewers for https://review.openstack.org/#/c/565358/
14:04:54 <njohnston> I did reach out to a couple people
14:05:28 <njohnston> so now it just needs to pass gate consistently
14:05:36 <lujinluo> yeah, it is waiting for final check now
14:05:45 <lujinluo> seems to get merged pretty soon
14:05:52 <lujinluo> thanks!
14:06:01 <njohnston> and second one we can check now, which is that the wiki page for this meeting seems quite out of date (refrences Pike in the future tense)
14:06:35 <lujinluo> yes, i am aware of that too. #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam there are too much out-of-date info
14:06:50 <lujinluo> but i am curious why you said you do not have right to edit it njohnston ?
14:07:01 <njohnston> I thought about updating it, but I did not feel I should without talking to you first, lujinluo.
14:07:21 <njohnston> I had an issue with my openstack id, which I have since sorted out
14:07:38 <lujinluo> i see. i thought it was some technical issues. but you are more than welcome to update it! njohnston
14:08:06 <njohnston> I think that was all :-)
14:08:19 <lujinluo> i will try to put the latest info tmr, but it would also be appreciated if you would help me with it too
14:08:38 <lujinluo> as one person may miss something :-)
14:09:04 <TuanVu> I'll also have a look
14:09:18 <lujinluo> thanks TuanVu !
14:09:19 <TuanVu> so if you push a new patch, please add me as well
14:09:28 <TuanVu> I'll try my best :)
14:09:42 <lujinluo> wiki page does not involve any patches
14:09:57 <lujinluo> anyone is free to edit after logging to openstack id
14:10:01 <TuanVu> oh, thanks for this info
14:10:12 <TuanVu> thank you, Luo
14:10:18 <lujinluo> yeah, then let us jump to the ovo patches first
14:10:22 <lujinluo> #topic OVO
14:10:40 <lujinluo> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db
14:11:02 <lujinluo> #link https://review.openstack.org/#/c/549168/ Router OVO
14:11:18 <lujinluo> it is still pretty red
14:11:52 <lujinluo> hungpv: are you still trying to solve all the failures?
14:13:36 <lujinluo> well, i think the author is not at the meeting right now.
14:13:46 <lujinluo> maybe we should move to the next patch first
14:14:16 <lujinluo> #link https://review.openstack.org/#/c/565358/  objects: don't refetch a non-list object field if it's None
14:14:42 <lujinluo> this patch is so ready to go. hopefully we can see it merged within today :)
14:14:44 <njohnston> another one waiting for the gate
14:15:17 <lujinluo> njohnston: yeah, the gate seems to be slow
14:16:00 <lujinluo> #link https://review.openstack.org/#/c/507772/ Network OVO
14:17:03 <lujinluo> TuanVu: so I followed the recent comments about renamed type
14:17:35 <lujinluo> to make sure i am not missing anything. the status is that we have not figured a way to deal with it, right?
14:17:49 <lujinluo> Ihar's suggestion is to add a compatible layer
14:18:37 <lujinluo> i have not had time to review the latest codes
14:18:57 <lujinluo> oops, Tuan is offline now..?
14:18:59 <njohnston> I think that one is nearly ready to merge, slaweq just has a couple of notes
14:19:21 <lujinluo> how about the issues mentioned by boden?
14:19:35 <TuanVu> sorry, there was something wrong with network connection
14:19:40 <TuanVu> I'll provide answer for Slawek's comment soon
14:19:56 <lujinluo> TuanVu: how about vmware-nsx's failures?
14:20:05 <lujinluo> resulted from renames types
14:20:33 <TuanVu> regarding to problem with vmware, as Ihar's comment, these changes are legit
14:20:44 <TuanVu> boden will check more and provide update later
14:20:53 <TuanVu> from vmware side
14:21:43 <lujinluo> i might be missing something here, but it looks to me Ihar's opinion is that we should change something on OVO side, to avoid those failures on customers' side. no?
14:22:17 <lujinluo> consumers i mean
14:23:14 <lujinluo> njohnston: i would like to hear your opinion
14:23:38 <TuanVu> that's what he means by providing compatibility layer
14:23:49 <TuanVu> but I think it makes the problem to be more complicated
14:25:24 <TuanVu> why not doing the "right" thing right away instead of making a layer to mix between "right" and "not right"?
14:25:27 <njohnston> It does make the change a bit more complicated, no doubt.  The alternative is to make this change and then to lok through all networking projects and propose changes to each of them that will follow suit with this change.  I think the compatibility layer is more graceful.
14:26:01 <TuanVu> thanks for the comment, Nate
14:26:33 <njohnston> Since you cannot dictate that another project changes something to match your change, either you do it yourself, or you make it so that they can keep functioning until they can make the needed change.
14:27:06 <TuanVu> hmm
14:27:44 <njohnston> Let's recheck the vmware-nsx test patch and see what the issues it sees are
14:27:58 <lujinluo> yes, agree with njohnston . but i think what i am missing here is that is this compatibility layer included in the patch already or not?
14:28:06 <TuanVu> so compatibility layer is a great option
14:28:26 <TuanVu> not yet, Luo-san
14:28:30 <lujinluo> which seems to me we do not have the compatibility layer yet
14:28:39 <TuanVu> yeah
14:28:48 <TuanVu> you're correct
14:29:00 <lujinluo> njohnston: good point. we shall recheck vmware-nsx and then see if boden has any updates
14:29:31 <njohnston> I just sent a recheck to https://review.openstack.org/574797/
14:29:38 <njohnston> which is the vmware-nsx test patch
14:30:00 <njohnston> shall we note an #action on this?
14:30:08 <lujinluo> #action to see the latest result of https://review.openstack.org/574797/
14:30:50 <lujinluo> #action lujinluo to check if bode has any updates on vmware-nsx side
14:31:19 <lujinluo> let's move to next two patches
14:31:33 <lujinluo> #link https://review.openstack.org/#/c/561834/ https://review.openstack.org/#/c/562489/
14:31:44 <lujinluo> these two are recently reviewed by manjeet
14:31:59 <lujinluo> TuanVu: you may not have had time to work on them yet
14:32:26 <lujinluo> oh, and one of them is reviewed by nate
14:33:11 <lujinluo> #link https://review.openstack.org/#/c/544206/ portbinding OVO
14:33:17 <TuanVu> in last week IRC meeting, Nate had provided some suggestion for doing "join"
14:33:38 <lujinluo> yeah, i was planning to have that discussion on open discussion part
14:33:49 <lujinluo> i have some questions regarding that
14:33:53 <TuanVu> however, as far as I remember, the details (eg: maybe a patch with example) haven't been decided yet
14:34:43 <lujinluo> njohnston: yeah, so i think i did not fully understand what dan suggested
14:35:10 <lujinluo> is he suggesting we should do 'joins' in a general way or we do them case-by-case?
14:35:56 <njohnston> It seems to me that his suggestion works well for a specific type of join, where we are taking data from one object and adding a few fields from a second object
14:36:37 <lujinluo> i see. i think we have other joins dealing with 3 tables
14:36:47 <njohnston> After looking at how the code works in Nova, it did not look to me like it would provide other functions that joins have, like "show me only the records that are in both table 1 and table 2"
14:36:48 <lujinluo> can his suggestion work on that situation as well?
14:36:53 <njohnston> Not as well.
14:37:21 <njohnston> So I think it is probably better to just rehome the joins into the objects.  This has already been done in a number of places, for example: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/ports.py#n200
14:37:56 <njohnston> or https://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects/router.py#n147
14:38:06 <njohnston> just a couple examples among many
14:38:06 <lujinluo> yes, we did that before
14:38:33 <lujinluo> it is kind of a historical reason as we could not find a good solution at that time
14:39:17 <njohnston> I don't think there is a good solution unless you have deep knowledge of the transaction in question.
14:39:25 <lujinluo> but last time when we had the discussion about whether we should continue doing that, Ihar said we should still try to find more ovo-like solutions and i agreed
14:39:59 <lujinluo> but if we still could not find it, i do not oppose the idea of moving joins into objects
14:40:14 <njohnston> I don't think we should hold up change based on this
14:40:15 <lujinluo> although i do think that is the last we want to do
14:40:38 <lujinluo> yes, i agree.
14:41:12 <njohnston> I don't want to delay the neutron upgrade core deliverable, which is what OVO is a means to, just based on the purity of OVO
14:41:33 <lujinluo> yeah, i understand that.
14:41:44 <lujinluo> then let's just move joins to objects
14:41:50 <njohnston> Once we get to the seamless upgrade that the OVO transition promises us, then we can revisit this.  Maybe we will have had a better idea in the meantime. :-)
14:42:07 <lujinluo> hopefully :)
14:42:10 <njohnston> Just my own personal opinion :-)
14:42:53 <lujinluo> sure, i do not want to block the delivery of ovo either.
14:43:08 <lujinluo> let's add TODOs when moving joins then
14:43:17 <lujinluo> to remind us of the debts!
14:43:41 <TuanVu> thank you, Nate and Luo for the discussion
14:43:43 <TuanVu> I got it
14:44:24 <lujinluo> ok, let's move to the next one
14:44:42 <lujinluo> #line https://review.openstack.org/#/c/544206/ portbinding ovo
14:44:46 <lujinluo> this one is on me
14:44:59 <lujinluo> i will rebase and address manjeet's comments tmr
14:45:13 <lujinluo> but i still need to wait for Migeuls' patch as well
14:45:32 <lujinluo> but if you feel like doing more reviews, welcome!
14:45:52 <lujinluo> the rest of the patches are not touched yet
14:45:57 <lujinluo> #open discussion
14:46:13 <lujinluo> #topic open discussion
14:46:22 <lujinluo> (vacation ruined my brain
14:46:47 <lujinluo> i have one thing that i would like to share
14:47:04 <lujinluo> as some of you might have already know, i am leaving my current employeer
14:47:43 <lujinluo> i have hand over most of my community and in-house duties to my colleagues, but i will continue working on neutron ovo
14:48:01 <TuanVu> that's awesome, Luo :)
14:48:16 <TuanVu> I'm very glad to know that
14:48:24 <lujinluo> since i am going back to school to pursue a higher education, i will spend as much time as i can on ovo as i used to
14:48:40 <njohnston> I hope it is a fantastic new adventure for you! Glad you will still be in the community.
14:49:15 <lujinluo> but if at some point of time in the future that i think i will not be spending that efforts, i will let you and Miguel know
14:49:55 <lujinluo> ok, that is all about what i want to share!
14:50:07 <lujinluo> does anyone have anything else?
14:50:31 <TuanVu> although it's sad to see you leave Fujitsu but at the same time, I'm very happy to know that you're about to have a new great adventure
14:50:46 <lujinluo> thank you! TuanVu and njohnston
14:50:51 <TuanVu> :)
14:51:02 <TuanVu> regarding to Network OVO patch
14:51:18 <TuanVu> compatibility layer
14:51:42 <TuanVu> I don't understand what Ihar means by "'port_security' property that returns 'security' value"
14:52:26 <TuanVu> and also "az_hints as string instead of a list of strings"
14:53:16 <njohnston> I did not go back and research those references, but I assumed he was listing examples of previous measures taken for compatibility shim reasons.
14:53:52 <TuanVu> yeah, I mean I'm not sure how to build the layer for the conversion
14:54:46 <lujinluo> i have not looked at the codes yet, but i think it is similar to the methods of from_db_object(), where you switching port_security in ovo and security in db
14:55:06 <njohnston> so right now vmware-nsx calls some function and expects to get back from that the data provided by sql alchemy, right?
14:55:31 <njohnston> so keep that function and the arguents the same, and have the function call whatever OVO methods accomplish the same result
14:55:39 <njohnston> that way the vmware-nsx code does not need to change
14:56:06 <njohnston> You may want to mark that it is being left for compatibility reasons in a comment
14:56:46 <njohnston> The same tactic has been used as functionality is migrated from neutron into neutron-lib
14:57:02 <TuanVu> thank you very much, Nate and Luo
14:57:12 <TuanVu> I will dig more
14:57:29 <TuanVu> if there's any other concern, I'll let both of you know :)
14:57:29 <lujinluo> no problem
14:58:00 <lujinluo> ok i guess that's all for today
14:58:05 <lujinluo> thank you guys!
14:58:09 <njohnston> keep asking questions; you're really close to it TuanVu!
14:58:12 <njohnston> Thanks all
14:58:17 <lujinluo> see you next week
14:58:23 <TuanVu> thanks a lot, Nate :)
14:58:32 <TuanVu> see you guys soon :)
14:58:33 <lujinluo> #endmeeting