15:01:21 #startmeeting neutron_upgrades 15:01:22 Meeting started Mon Nov 28 15:01:21 2016 UTC and is due to finish in 60 minutes. The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:25 The meeting name has been set to 'neutron_upgrades' 15:01:26 howdy 15:01:27 hello 15:01:29 Hi 15:01:31 hi 15:01:35 giving a minute for everyone to join... 15:02:42 thanks to Thanksgiving, I could catch up with reviews 15:02:46 Hi 15:02:59 sorry was pulled by someone evil! 15:03:02 but now I am back 15:03:03 #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda 15:03:20 #topic Announcements 15:03:46 nothing to report here I believe. please register for PTG in Feb 2017 ;) 15:03:55 #topic Partial Multinode Grenade 15:04:15 I think jschwarz is still working on linuxbridge grenade job 15:04:40 I am 15:04:50 there is a patch that should have helped: https://review.openstack.org/#/c/400258/ but it does not seem like it fixed the failure as seen in http://logs.openstack.org/59/396659/2/experimental/gate-grenade-dsvm-neutron-linuxbridge-multinode-nv/f652b83/logs/testr_results.html.gz 15:05:22 it's probably because the fix is for neutron-legacy and not for neutron 15:05:25 jschwarz: for what I understand, it seems like nova tries to land a port on a compute node that is (no longer) registered in neutron-server 15:05:30 I'm gonna port it to both ways and see if it works 15:05:37 jschwarz: do we use lib/neutron for the job? 15:05:53 jschwarz: you can check devstacklog to determine it 15:05:57 ihrachys, that's what I wasn't sure of - I implemented the fix for lib/neutron-lib iirc 15:06:04 ihrachys, will have a thorough look now 15:06:14 jschwarz: you mean -legacy not -lib right? 15:06:20 ihrachys, sorry yes 15:06:50 jschwarz: seems -legacy: http://logs.openstack.org/59/396659/2/experimental/gate-grenade-dsvm-neutron-linuxbridge-multinode-nv/f652b83/logs/grenade.sh.txt.gz#_2016-11-23_11_12_09_237 15:07:00 jschwarz: I am actually not sure if we use lib/neutron anywhere in our own gate 15:07:05 which is a shame ;0 15:07:19 ihrachys, ack 15:07:20 like, how is it legacy if it's used for everything? :) 15:07:29 jschwarz: so I believe your fix applies 15:07:32 ihrachys, so I'm not sure why it didn't work for legacy 15:07:37 jschwarz: but does not help the issue 15:07:45 ihrachys, I'm gonna look if my code actually ran through 15:08:00 jschwarz: I am sure it did. but why do you think it's enough to pass? 15:08:19 jschwarz: yeah, sure, agent now starts; but it's neutron-server that fails to schedule binding to a (non-existing) agent 15:08:29 ihrachys, the failure in the logfile mentions that the linuxbridge agent failed because br-ex didn't exist when it started 15:08:43 ihrachys, the agent doesn't start 15:08:44 in the job I posted a link to? 15:09:04 ihrachys, yes 15:09:05 ihrachys, http://logs.openstack.org/59/396659/2/experimental/gate-grenade-dsvm-neutron-linuxbridge-multinode-nv/f652b83/logs/subnode-2/old/screen-q-agt.txt.gz 15:09:20 oh right 15:09:28 I think I understand what's going on 15:09:34 that's subnode, it runs 'old' code 15:09:38 including old devstack 15:09:45 ihrachys, how old? 15:09:48 we would need to backport it to newton for devstack 15:09:59 jschwarz: like newton old 15:10:11 ihrachys, ah. 15:10:30 ihrachys, so, I can start a backport and change the depends-on for the DNM patch and see if the fixes it :P 15:10:42 jschwarz: so probably the path forward is to try to backport the fix (without landing master just yet), then retrigger DNM with both patches (master and newton) included 15:10:49 ihrachys, or, rather, it wouldn't work because the subnode takes the stable/newton code no matter what? 15:10:51 jschwarz: you don't need to change change-id 15:10:55 jschwarz: since it's the same for backport 15:11:05 jschwarz: and zuul should correctly capture both matching 15:11:24 ihrachys, question is, will it use the new stable/newton patch for the subnode as well 15:11:35 ihrachys, or is it hard-coded to always be stable/newton or something 15:11:35 jschwarz: if you depend on both master fix and newton backport, zuul should correctly gate with both included on both nodes 15:11:40 ok 15:11:42 will do it now 15:11:47 if not, that's a bug in zuul setup for the job 15:11:50 jschwarz: cool 15:12:06 ihrachys, https://review.openstack.org/#/c/403752/ 15:12:25 jschwarz: btw be aware I switched the job to xenial lately https://review.openstack.org/#/c/402488/ 15:12:29 ihrachys, and triggered a recheck experimental 15:12:38 jschwarz: should not break anything, but I won't guarantee 15:12:40 ihrachys, Aye I saw - that was a quick merge :) 15:12:47 jschwarz: I think it's 'check experimental' not recheck 15:12:52 ihrachys, worst case scenario I'll know who to yell at 15:12:57 ihrachys, yeps, that's what I did :) 15:13:12 jschwarz: the more friends in infra you get the quicker you merge patches ;) 15:13:21 ihrachys, :D 15:13:30 ok I guess we settled the path forward here. cool. 15:13:41 happy to be of service 15:13:57 on the other front, I believe all other grenade jobs in neutron gate switched to xenial already with no issues 15:14:06 #topic Object implementation 15:14:18 #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db 15:14:46 some patches landed lately are: 15:14:47 address scope integration: https://review.openstack.org/308005 15:14:56 provider resource association: https://review.openstack.org/304322 15:15:18 objects_exist API in the merge queue: https://review.openstack.org/395748 15:15:32 also subnet service type should be ready to merge: https://review.openstack.org/375536 15:15:47 rossella_s: ajo: blogan: ^ please review the latter one 15:16:07 ihrachys, ack 15:16:29 ihrachys, objects_exists is dependent on a OVO patch. It wont merge until the OVO gets merged? 15:16:29 I was reviewing some more lately, but so far I haven't found anything more to land 15:16:36 sshank: oh 15:17:05 ok I will give that dep patch a go after the meeting, it has +1 for korzen so should be in good shape 15:17:19 ihrachys, Thanks. 15:17:28 of common interest, there is also a patch that modifies our UUIDField approach: https://review.openstack.org/#/c/393150/ 15:17:36 ihrachys: what about the integration of router route? 15:17:42 it will affect all patches introducing UUIDField based objects once landed 15:18:47 electrocucaracha: that's integration only right? 15:18:57 will review right after 15:19:11 ihrachys: yeah, the creation was merged couple of weeks ago 15:19:15 ihrachys: thanks 15:19:35 so folks, make note of that UUIDField patch I mentioned above 15:19:52 once landed, it will break some of patches introducing objects with a UUIDField 15:20:09 the fix is easy - replacing obj_fields.UUIDField with common_types.UUIDField 15:20:28 but we will need to do that across the board for all new objects 15:21:20 I see dasm also respinned the patch that switches all existing objects from tenant_id to project_id: https://review.openstack.org/#/c/382659/ 15:21:28 ihrachys: does that mean that we have to consider this new approach for current ovo implementations? 15:21:40 electrocucaracha: you can't until we land the new type class 15:22:00 electrocucaracha: so for now stick to what we have (obj_fields.UUIDField), and we will adopt when the patch actually lands 15:22:04 ihrachys: yep. came back from vacations ;) 15:22:13 it may take some time to land since the author is new to the team 15:22:26 dasm: cool. I will have a look. 15:22:46 ihrachys: it's still not ready, but it's getting better. hopefully sooner than later. 15:22:57 also, some of you folks may have noticed that there is ongoing work in the tree to switch to a new oslo.db enginefacade 15:23:13 ihrachys: when it'll be in good shape, i'll ping you, korzen and electrocucaracha to take a look at it 15:23:18 that replaces all autonested_transactions context managers with specific reader/writer managers. 15:24:06 * ihrachys tries to find an example 15:24:08 ihrachys, does enginefacade help with detached db_obj problem? 15:24:26 ihrachys: there are plenty for rebasing merge conflicts 15:24:49 the integration of subnet and network OVOs are dependent on db_obj being detached from the session 15:24:52 korzen: no I don't think so. actually, Anna mentioned to me that we may need to rethink expunge calls because apparently they are not working with the new facade 15:25:08 ihrachys: https://review.openstack.org/#/c/306685/21/neutron/db/flavors_db.py@109 15:26:07 electrocucaracha: thanks!!! 15:26:10 ihrachys, the expunge does not work either so 15:26:22 it is good that we need to change it ;) 15:26:31 yeah, so you see, in the patch, we remove the writer.using context manager, same way we could do for autonested_transaction 15:26:45 we will probably need to switch our object classes to using the new context managers too 15:27:08 meaning, use writer.using for create/update/delete and reader.using for get_object[s], count, objects_exist 15:27:34 korzen: I am not filled in with details on why they are not compatible, but I trust Anna's judgement :) 15:28:24 electrocucaracha: btw that flavour patch, does it seem like ready? 15:28:33 I don't see any TODOs or WIP markers 15:28:54 ihrachys: nope, I need to check the latest errors, it was fine before 15:29:37 actually I have plans to review Qoutas first before that one https://review.openstack.org/#/c/338625/ 15:30:23 electrocucaracha: I see korzen already chimed in there with a -1. are they interdependable for some reason? 15:32:17 ihrachys: I haven't have time to take a look, but the good thing about that patch is that contains four objecst 15:32:38 * ihrachys makes notes 15:32:45 * ihrachys opens more tabs 15:33:44 ok let's move on to the next topic 15:33:49 #topic Other patches on review 15:34:07 ok one thing I wanted to mention 15:34:17 docs team plans for a common openstack upgrades guide 15:34:20 #link https://review.openstack.org/#/c/394261/ 15:34:26 atm it's in spec stage 15:34:55 but it's still worth having a look, and I expect us to help folks later with the content on neutron 15:36:59 anything more on your plate of common interest? 15:37:47 ihrachys: I was thinking about the testing on null ids 15:38:10 electrocucaracha: ah right. you mean the test for db_obj? 15:38:17 I'm working on devref: https://review.openstack.org/#/c/336518 15:38:41 anyone that still did not review it, please do 15:38:42 ihrachys: the discussion that was started on the router patch 15:38:49 electrocucaracha: we indeed can't create an object without foreign keys properly set, so we definitely need to create objects there. 15:39:07 electrocucaracha: I need to digest the rationale and see if it means that in this case the test case is worthless 15:39:33 korzen: electrocucaracha: I guess the explanation to skip the test case for the field that can't be null is that db_obj. will always be non-null there? 15:39:40 ihrachys: yeah, my only concern is that we are not testing the scenarios where the id is set as null 15:40:32 ihrachys, yes 15:40:45 ihrachys, well it is not skipping the test 15:40:48 electrocucaracha: I think the scenario that is not covered is when you maybe decide to change the value of the foreign key value. it should be doable right? 15:41:03 from general model perspective, not necessarily from business logic perspective 15:42:12 well that's another one, I was thinking in the case where you have an optional foreign keys 15:42:35 If I remember SecurityGroupRules has one 15:42:47 yeah, we may want to work on the base test framework to add some test cases for those corner cases. 15:43:07 more things to the TODO list :) 15:43:12 then we should be safe to skip the existing test case for the fields 15:43:33 electrocucaracha: I will revisit the vote though, I don't think it's worth a block 15:44:27 ok 15:44:59 #topic Open discussion 15:45:15 ihrachys, korzen Regarding standard attribute, we started a WIP patch. 15:45:23 sshank: link? 15:45:39 ihrachys, korzen: https://review.openstack.org/#/c/400412/ 15:45:59 ok thanks 15:46:10 not sure if the idea is correct. 15:47:19 sshank, taking a quick look at it, it needs more work ;) 15:47:22 sshank: the idea is but implementation is not correct. I will leave a comment. 15:47:32 yea, exactly 15:47:51 ihrachys, Ok. Thanks 15:47:58 sshank: and we will need some test cases for the feature 15:48:05 so from other news, the distributed port binding for live migration is going to extend the PortBinding with host_id and status fields, host_id being primary key 15:48:33 korzen: ok that was the decision in the spec? I haven't checked since I left the comments last time. 15:48:49 yes, it didn't change 15:49:09 for those wondering, we are talking about https://review.openstack.org/#/c/309416/33/specs/ocata/portbinding_information_for_nova.rst@555 15:49:36 the concern was that using DistributedPortBinding rework will take more time than extending 15:50:12 korzen: ok, so from OVO/downtime-less upgrades perspective, status field should be easy (probably no actual work) 15:50:27 ihrachys: korzen: is there any impact if we extend the primary key while expand migration? 15:50:37 korzen: as for primary key extended to cover host, I believe it's also ok because we are migrating from 1 to many 15:51:31 hm 15:51:39 it makes me think that it may be actually a problem 15:52:01 I hope that extending the primary keys will not block the DB for much time? 15:52:31 I need to draw some lines on a piece of paper to make sense of it 15:52:42 from no-downtime, it is the bigger problem 15:53:08 is it backwar compatible? 15:53:26 yea. the current newton code assumes that there is only a single object to return when fetching by port_id 15:53:41 if you will do the insert/select without second primary key? 15:54:17 korzen: I don't think we actually have code that would do that, but I suspect we may have code that does not pass host on fetch 15:54:46 ok we need to make sense of the idea before it's too late :) 15:55:25 if the change will not be backward compatible then we are doomed 15:55:43 not mentioning many lines of code at OVO side 15:55:54 to handle the empty host_id etc 15:55:59 migrating data 15:57:13 I will need to fetch newton code and read it through to understand how we use the table right now. 15:58:13 korzen: thanks for raising the flag, it's a very important piece of the puzzle for Ocata 15:58:40 btw we are still to look at CI setup for mixed API endpoint versions. 15:59:14 ok, we have 1 min left, let's call it a day and spend the minute for reviews ;) 15:59:20 thanks everyone 15:59:31 I will walk thru patches mentioned during the meeting right now 15:59:33 cheers 15:59:37 #endmeeting