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