14:00:07 #startmeeting neutron_upgrades 14:00:09 Meeting started Thu May 31 14:00:07 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:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:13 The meeting name has been set to 'neutron_upgrades' 14:00:18 o/ 14:00:23 Hi Luo-san 14:00:33 hi TuanVu ! 14:01:07 We do not have any AIs from last meeting 14:01:15 so jump into OVO patches 14:01:17 https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db 14:01:25 #topic OVO 14:01:30 ok 14:01:42 https://review.openstack.org/#/c/570244/ 14:01:47 this one is from Nate 14:01:59 o/ 14:02:05 The codes look fine to me. but Zuul failed last time 14:02:08 hi njohnston 14:02:16 There is an issue with the sphinx docs build job 14:02:24 let's wait for the result of Zuul and see how it goes 14:02:44 njohnston: does the latest patch solve it? 14:02:51 I have https://review.openstack.org/#/c/571301/ to fix it, but I saw there was a discussion between boden and haleyb about whether it was the right approach. 14:03:27 I rebased 570244 onto 571301 and the build-sphinx-docs job has already succeeded so I believe it will build 14:05:11 i see. from a rough review, i think it will fix it 14:05:33 hopefully so :-) 14:05:55 yeah 14:06:15 next is https://review.openstack.org/#/c/507772/ 14:06:30 I’ve already left a comment about latest status on the patch 14:06:30 i think you have already fixed the RBAC issue? TuanVu 14:06:39 yes :) 14:07:00 good! i see. tempest is still failing 14:07:15 thanks to the help from both you and Ihar :) 14:07:32 yeah, I'm not sure how to fix it at this moment 14:07:42 so any suggestions are welcome 14:08:31 it looks like it's related to attach qos 14:08:38 are the failed tests related to qos policies? 14:08:51 yes, I think so 14:08:59 neutron_tempest_plugin.api.test_qos.RbacSharedQosPoliciesTest.test_network_presence_prevents_policy_rbac_policy_deletion [5.378070s] ... FAILED 14:10:13 also, slawek pointed potential failures of mtu 14:10:19 have you checked that as well? 14:10:41 yes, I've checked that 14:11:03 it looks like there's problem with getting mtu in: 14:11:04 https://review.openstack.org/#/c/507772/54/neutron/plugins/ml2/plugin.py 14:11:08 is it one of the 5 failed tests? 14:12:21 yes 14:12:37 neutron_tempest_plugin.api.test_trunk_negative.TrunkTestMtusJSON . test_add_subport_with_mtu_greater_than_trunk 14:12:47 & 14:12:53 test_create_trunk_with_mtu_smaller_than_subport 14:13:08 ok, i think i need a bit more time to catch up with the latest patch. will take a closer look rmt. but i understood the current status 14:13:33 thank you in advance, Luo-san :) 14:14:12 next https://review.openstack.org/#/c/565358/ 14:14:17 this one is from Ihar 14:14:40 and it is blocked by sphinx docs issue 14:15:47 we may need to recheck it after Nate's patch got merged 14:16:04 yeah, I think so 14:16:13 i have added more core reviewers to 571301. hopefully they will take time to review it 14:16:48 https://review.openstack.org/#/c/544206/ this one is on me 14:17:24 i have two remaining AIs for this patch: 1) reabse it on Migule's patch; 2) resolve the postgresql issue exposed last time 14:18:08 for 1) I plan to wait for Miguel's patch to get merged, https://review.openstack.org/#/c/414251/. and it is very close to be merged now 14:18:47 for 2) i need to talk to Ihar, because i could not find which test is deployed with postgresql as backend 14:19:16 if you know which one it is, or you know how i can find it out, please help me out 14:20:47 ok, i will try to catch ihar or Miguel or slawek tmr.. 14:21:02 https://review.openstack.org/#/c/537320/ this one is still on me.. 14:21:39 i rebased it to accommodate auto detect engine facade 14:22:01 but i have one tempest failure, which i believe is related to my change 14:22:10 i will work it out tmr 14:22:26 (tmr seems to be a tough day for me) 14:22:53 yeah 14:22:59 but please take it easy, Luo 14:23:07 TuanVu: haha, thanks! 14:23:17 :) 14:23:30 we do not have any updates of the remaining patches 14:23:39 does anyone want to address any of their patches? 14:23:50 yeah 14:23:55 shoot 14:24:25 i have a few questions, maybe basic ones, but you know I'm still noob :D 14:24:39 no problem at all. will try my best 14:24:40 https://review.openstack.org/#/c/549168/8/neutron/tests/unit/extensions/test_l3_ext_gw_mode.py 14:25:11 L149 self.context.session.flush() 14:25:56 i'm not sure is this one necessary or not 14:26:30 after converting to OVO, we do not need it anymore. .flush() commits all the pending commits to the sessions, because after calling .add() all the commits are not actually commited, they are in pending state 14:26:43 that's great! 14:26:44 while in OVO world, a create() is a commit to db 14:27:17 good. anything else you want to discuss? 14:27:32 yes, and about create() function 14:27:46 sure 14:28:06 i saw some patches rewrite it, not use the built-in one in base.py 14:28:20 can you give some ideas about it? 14:28:40 what situations we should do this one or other? 14:29:16 yeah, normally create() in base.py does the basic stuff. but for some OVO objects, they have special fields, which are not defined in base.py, then it'd better to rewrite 14:29:29 let me try to find an example here 14:30:19 https://github.com/openstack/neutron/blob/master/neutron/objects/ports.py#L344 14:31:05 Port has QoS and security groups as extensions attaching to it 14:31:47 but QoS and security groups are loaded as synthetic field, thus you need to add additional methods to attach them 14:32:02 i see 14:32:35 sorry QoS and security groups are NOT loaded as synthetic field 14:33:05 so it really depends on what object you are dealing with 14:34:16 i've got your point 14:34:29 great! 14:35:10 anything else you want to discuss? 14:35:27 yeah, one final question 14:35:46 sure 14:36:09 L267 router.gw_port.mac_address) 14:37:06 if I understand it, I see router db model calls mac _address of gw_port 14:37:35 just sure how to convert it when dealing with router object 14:38:10 can you shed me some light on it? thank you 14:38:22 hmm, i do not quit understand your question 14:38:42 do you mean you want to know how to deal with gw_port and router objects? 14:39:41 yes, that's where I'm stuck right now 14:39:58 thank you for quick understanding 14:41:01 as far as i recall, we may need to add port as a synthetic field of router's in order to proceed. but this is a bit tricky. can you try if we can call router.db_obj.gw_port to request gw_port from db model 14:41:05 just an idea though 14:41:47 can you point me to the patch? i can add one more task to my to-do list for tmr.. 14:42:13 @luo-san: https://review.openstack.org/#/c/549168/ 14:42:21 A reference to router.gw_port works on L269, so I would expect "router.gw_port['mac_address']" might have a chance of success. 14:43:10 Thank you Nate, gonna try it out 14:43:34 yeah, worth a try 14:45:13 ok, i will review the patch tmr 14:45:22 so nothing more from me. thank you 14:45:39 #topic open discussion 14:45:43 I'm prepare a new patch, and will update tmr for review 14:45:58 understood, please add us as reviewers 14:46:17 yes, surely 14:46:33 does anyone have anything to talk about? 14:46:45 none from me 14:47:30 cool! now let us call it a day! 14:47:39 have a good night/day everyone 14:47:43 see you next week 14:47:54 #endmeeting