15:00:34 #startmeeting neutron_upgrades 15:00:35 Meeting started Mon Nov 14 15:00:34 2016 UTC and is due to finish in 60 minutes. The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:38 The meeting name has been set to 'neutron_upgrades' 15:00:42 hey folks 15:00:43 hola 15:00:54 Hi 15:01:01 hello 15:01:31 #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda 15:01:43 Hi 15:02:08 #topic Announcements 15:02:15 Hello 15:02:18 O-1 is this week 15:02:31 also, some folks are working on switching gate to all Xenial 15:03:09 from upgrades standpoint, the most interesting of the latter is the following: Newton/Ocata branches will run on Xenial 15:03:20 Hello. 15:03:20 BUT: grenade jobs will still run on Trusty (for Newton) 15:03:41 this is because grenade for Newton validates Mitaka -> Newton upgrade, and Mitaka is supposed to be Trusty 15:03:42 Hi 15:03:53 you may notice some reshuffling of gate jobs in all branches in next days 15:03:58 actually, it already occurs :) 15:04:12 I don't have any more public announcements for you 15:04:18 #topic Partial Multinode Grenade 15:04:35 ok, that one, I actually looked at logs and made some progress (I hope) 15:04:54 first thing I noticed was that for some reason, we were starting OVS agent on the new side of grenade 15:05:12 I came up with a simple patch for that issue: https://review.openstack.org/#/c/396658/ 15:05:30 ihrachys: is it the reopened bug of the other day? 15:05:41 electrocucaracha: I don't know what you refer to 15:05:48 electrocucaracha: if you mean ryu one, no 15:06:02 ihrachys: yeah, that one... ok 15:06:12 electrocucaracha: but that's a good call, I will touch it later 15:06:34 so, with the patch above, I triggered experimental tests again at: https://review.openstack.org/#/c/396659/ 15:06:53 and it's actually very promising 15:06:59 the test results for the run: http://logs.openstack.org/59/396659/1/experimental/gate-grenade-dsvm-neutron-linuxbridge-multinode-nv/97289d8/logs/testr_results.html.gz 15:07:07 note there is a single test that actually failed 15:07:10 test_schedule_to_all_nodes 15:07:49 I *suspect* there is some setup error where nova maybe tries to schedule an instance for a node that does not run a neutron l2 agent 15:08:00 more investigation is needed though 15:08:20 jschwarz: will you have time this week to look at the failure in linuxbridge grenade multinode job? 15:08:46 with that remaining failure fixed, I believe we will be able to fix the job and move it into check queue 15:09:10 actually, anyone interested may step in and try to fix the failure 15:10:24 ok seems like no one is truly interested ;) 15:10:32 moving on 15:10:33 * electrocucaracha would like but he'll be bug deputy this week 15:10:44 #topic Object implementation 15:10:54 #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db 15:11:02 we landed some patches the previous week 15:11:20 most notably, dns integration: https://review.openstack.org/381333 15:11:48 some preparations for adoption of objects in tree: https://review.openstack.org/357787 and https://review.openstack.org/363206 and https://review.openstack.org/394627 15:12:15 finally, DuplicateEntry is now retriable on API/plugin level: https://review.openstack.org/377084 15:12:25 thanks the authors and reviewers 15:13:05 ihrachys: there are several patches that depends on router and agent ovo, not sure if we can consider them for high priority? 15:13:16 electrocucaracha: yes. links? 15:13:21 https://review.openstack.org/#/c/307964/ Router 15:13:37 https://review.openstack.org/#/c/297887/ Agent 15:14:44 * ihrachys copied the links into his trello board and will give them priority 15:15:26 I have a question, about adoption and TODOs on port and network OVOs 15:15:42 I will take care of Network OVO adoption 15:15:49 anyone is interested in port? 15:16:45 I probably won't be able to give it a run this week 15:16:53 do we have a WIP at least? or it's all new work? 15:17:19 all new 15:17:20 * electrocucaracha is reviewing https://docs.google.com/spreadsheets/d/1FeeQlQITsZSj_wpOXiLbS36dirb_arX0XEWBdFVPMB8/edit#gid=1434170112 15:17:46 my more humble plan for the next steps is to land all binding related objects 15:17:57 because work that will involve them is in line for Ocata 15:18:36 ihrachys:korzen: https://review.openstack.org/#/c/382567/ 15:19:25 ihrachys, what do you mean by bondings? 15:19:30 bindings* 15:20:12 korzen: port binding objects like the one specified by ndahiwade above. remember the design session where changes to bindings API were discussed? that will involve change in db schema. 15:21:05 ok 15:21:07 that one 15:22:07 I have reviewed the spec and patches from andreas_s but I did not have time to contact with him 15:22:34 oh that's cool. you are a lot more rapid than me. 15:22:51 do you see any issues with the approach proposed that could affect us? 15:23:32 it is not clear to be which way we should go 15:24:10 because we should use the distributed port binding instead of port regular binding? 15:24:25 hi korzen, brianstajkowski and his team will take over the work on the portbinding item, so for future question, please take him into the loop 15:24:48 andreas_s: oh. are you pulled from neutron or just this specific thing? 15:25:40 korzen: from our POV it should not matter as long as we are ready with objects and integration for both? 15:26:37 andreas_s, just this specific thing, but I'm getting more involved into other projects, so I very welcomed that :) 15:26:38 I mean that there is no sense to add new attributes for port binding, if we have distribted port binding fitting the job nearly perfectly 15:27:12 korzen: oh you suggest that no new model will show up? 15:27:29 ihrachys, that is my understanding 15:27:34 korzen: we still probably need to support the flow where you have a legacy binding, then add a new host to it. 15:27:35 fomr DB and OVO 15:27:47 from db and ovo point of view 15:28:12 but that may be just business logic messing with two types of objects I guess 15:28:21 with no facade hiding transition 15:29:41 ok let's move on 15:29:48 #topic Other patches on review 15:30:04 not a patch exactly, but probably relevant, something that electrocucaracha mentioned already 15:30:17 there is a bug where agent restart fails 15:30:24 that affects grenade jobs in gate 15:30:31 it's not specifically upgrade related 15:30:54 it fails to start the agent because the new instance of the agent fails to start Ryu controller 15:31:01 and this is because the old one is left running 15:31:04 the bug is https://bugs.launchpad.net/neutron/+bug/1611237 15:31:04 Launchpad bug 1611237 in neutron "Restart neutron-openvswitch-agent get ERROR "Switch connection timeout"" [High,Confirmed] 15:31:17 turned out that's some bug in 'psmisc' package actually 15:31:23 that is not going to be fixed in trusty 15:31:47 that should be fixed for Newton+ with the Xenial switch, hopefully 15:32:18 as for Mitaka, well... the bug shows up only with of_interface = native that was CLI by default back then, so it's not hitting us in gate 15:32:42 so we are probably ok-ish 15:32:50 ihrachys, korzen Can you please review patch: https://review.openstack.org/#/c/395748/ . It was introduced since it was asked to be introduced in patch: https://review.openstack.org/#/c/361303/20/neutron/db/provisioning_blocks.py@169 15:33:27 sshank: ack 15:33:40 yes I wanted to discuss it 15:33:55 meaning the 'any_object' new method name 15:34:06 but we can continue on gerrit 15:34:12 As korzen mentioned, I find possible usages of this in 2 places. Here: https://review.openstack.org/#/c/381209/14/neutron/db/l3_hamode_db.py@762 and the above provisioning block patch. 15:34:51 why isn't count() enough? 15:36:10 ok nevermind, let's discuss on gerrit 15:36:22 ihrachys, Ok. Thanks. 15:36:25 I don't know of any more patches requiring particular attention. 15:36:38 ihrachys: korzen: need some reviews for the OVO patches :)(https://review.openstack.org/#/c/356660/, https://review.openstack.org/#/c/362508/, https://review.openstack.org/#/c/360908/) 15:36:53 of course you we do need, yes! 15:36:59 *you we -> we 15:37:09 thank you :) 15:37:24 I have lost the count of how many reviews are in queue 15:37:27 ;) 15:37:32 haha 15:37:48 it scares me too 15:37:50 so yes, please ping me if you have something urgent 15:38:13 I have 800+ messages in my review mailbox 15:38:16 right, I find it beneficial if people ping me on irc from time to time with things they believe are ready 15:38:31 of course I already have enough for a next day 15:38:45 but you can pull me into more later in the week :) 15:38:54 #topic Open discussion 15:39:13 :) 15:39:33 ihrachys: korzen: Can you guys take a look at this error:http://paste.openstack.org/show/589137/? 15:39:44 well, regarding Allocation and Endpoint objects I consoled them in a single patch https://review.openstack.org/#/c/396327/ 15:39:47 In this patch:https://review.openstack.org/#/c/382567/ 15:41:01 It persists after vif_details was changed in PortBinding and DistributedPortBinding Objects 15:41:27 ndahiwade: that sounds familiar to me, maybe it's the way the it's parsing the vif_details property 15:41:56 ndahiwade, it looks like in OVO there is dict but code is passing string 15:42:36 korzen:electrocucaracha: ack,not sure how to solve this one 15:42:43 right. we should find where it hits the object (it's in stack trace) and see if we need to convert json into a dict at that point 15:43:01 Debugging leads me to PortBinding OVO integration 15:43:34 maybe adoption code should pass dict, and before OVO core code was using the JSON in string 15:43:50 ndahiwade, I will take a look tomorrow 15:43:59 korzen:Thanks:) 15:44:01 yeap. I think we should convert somewhere in line 507 of plugin.py 15:45:04 anyone is interested in docs: https://review.openstack.org/#/c/336518/ 15:45:23 ooooh right 15:45:27 I completely forgot about it 15:45:34 * ihrachys adds another link into his todo list 15:45:45 I will need to update it a bit but please review until it will be obsolete 15:45:50 again 15:46:00 :) 15:46:02 :) 15:46:06 ihrachys, korzen, Patch: https://review.openstack.org/#/c/382037/ is related to port binding levels. Can you please review it? 15:46:10 you don't sound too optimistic 15:46:15 I should prove you wrong!! 15:46:43 ok, do we have any specific team wide topic to run, or we call it a day? 15:46:48 regarding the patch that I mentioned before(https://review.openstack.org/#/c/396327/), I created to make easier the integration 15:47:19 ack 15:47:24 ok, let's end the meeting then 15:47:26 korzen, Any idea how to go about the standard attribute OVO? 15:47:40 * ihrachys holds back 15:48:18 sshank, not yet 15:48:42 I guess that we can try some private OVO using the db_obj stored 15:48:47 in every object 15:49:07 but it can be specific for only Port 15:49:25 or maybe not standard-attr ovo but only property 15:49:34 that would be easier 15:49:55 if we care only on standard-attr-id 15:50:07 s/on/about 15:50:13 korzen, yes only the ID is necessary. 15:50:58 so it can be added as property returning self.db_obj.standard_attr_id 15:51:25 yeap. 15:51:45 if we are going to use property, it can be added to every object 15:51:51 or just make it base but exposed only for objects with stdattr. 15:51:58 yes 15:52:11 that is what I meant 15:53:00 if anyone wants to send such a patch, I am happy to jump there with reviews. 15:53:08 ok thanks for joining, again 15:53:11 and keep up 15:53:13 #endmeeting