14:00:55 <ihrachys> #startmeeting neutron_upgrades
14:00:55 <openstack> Meeting started Thu Jul 20 14:00:55 2017 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:58 <openstack> The meeting name has been set to 'neutron_upgrades'
14:01:16 * ihrachys waves at lujinluo
14:01:23 <ihrachys> we'll wait for a bit for manjeets
14:01:25 <lujinluo> o/
14:01:27 <lujinluo> sure
14:03:26 <ihrachys> hmmm
14:03:50 <ihrachys> looks like Manjeet is struggling with the new time ;)
14:03:56 <ihrachys> anyhow, let's walk through what we have
14:04:00 <lujinluo> haha, sure
14:04:04 <ihrachys> #topic Actions from previous week
14:04:15 <ihrachys> this week we have 3 items
14:04:17 <ihrachys> all on me
14:04:27 <ihrachys> neither done :-x
14:04:43 <lujinluo> :-x
14:04:55 <ihrachys> first was "ihrachys to take over port binding level OVO" and I just started looking but didn't get to anything meaningful
14:05:08 <ihrachys> second was "ihrachys to review CLI patch for data migration" and I haven't had a single look :-x
14:05:16 <ihrachys> and second was "ihrachys to take a look at https://bugs.launchpad.net/neutron/+bug/1704000"
14:05:17 <openstack> Launchpad bug 1704000 in neutron "Sometimes OVO unit tests clash on non-unique attributes" [High,In progress] - Assigned to Lujin Luo (luo-lujin)
14:05:39 <ihrachys> for that, lujinluo took it over because he needs to do a similar fix for floating ip OVO
14:05:48 <ihrachys> lujinluo, thanks for that :)
14:05:59 <lujinluo> no problem. hmm, btw, it should be she ;)
14:06:07 <ihrachys> oops sorry
14:06:18 <lujinluo> haha, never mind
14:06:35 <ihrachys> well that's an embarrassing assumption actually :) anyhow.
14:07:05 <lujinluo> don't worry about that. it happens a lot.. ;)
14:08:03 <ihrachys> yeah
14:08:09 <ihrachys> #topic Gate breakages
14:08:21 <ihrachys> so one is on lujinluo that is the unique constraint failures
14:08:39 <ihrachys> lujinluo, you mentioned in gerrit that it may not help with the bug though, or am I misread?
14:09:16 <lujinluo> yes, it seems to be not related. but i am still trying to put them together
14:09:33 <lujinluo> because how we deal with unique tuples
14:10:02 <lujinluo> currently when unique tuples are found, we jump back to gent_random_object_fields()
14:10:42 <lujinluo> but in RouterL3AgentBinding's case, the composite unique key is within update_object_fields()
14:11:08 <lujinluo> so we will end up in a infinite loop
14:11:47 <ihrachys> oh. but then how do tests work? I think we create all three objects from the generated fields, no? they would fail on creating the second one?
14:11:59 <ihrachys> or maybe we don't really create all three?..
14:12:55 <lujinluo> the creation is in update_object_fields() and we do not have unique key check in it. i am trying to add it
14:13:40 <ihrachys> ack
14:13:57 <lujinluo> but even though i add the check in update_object_fields(), when we found the unique tuple in get_randon_object_fields(), it ends up in infinite loops generating random values. need to take closer look tmr
14:15:43 <ihrachys> ok. if you feel that's a separate matter and not really related, we may remove Closes-Bug and have a fix just for your thing, no need to lump then
14:15:57 <lujinluo> ok, got it.
14:16:10 <ihrachys> speaking of other breakages triggered by OVO, we hit this in Red Hat CI for Pike: https://bugzilla.redhat.com/show_bug.cgi?id=1470784
14:16:11 <openstack> bugzilla.redhat.com bug 1470784 in openstack-neutron "The API test test_associate_floating_ip_with_port_from_another_tenant fails" [Unspecified,Assigned] - Assigned to ihrachys
14:16:34 <ihrachys> since switch to IPAllocation OVO, we get this when retry is triggered:
14:16:34 <ihrachys> 2017-07-13 15:20:51.064 85185 ERROR neutron.pecan_wsgi.hooks.translation FlushError: New instance <IPAllocation at 0x8b3f7d0> with identity key (<class 'neutron.db.models_v2.IPAllocation'>, ('2003::1:f816:3eff:fe3f:aa00', '8032a1cd-9236-4126-83fa-2f039ed2b890', 'c0542b84-bcd0-48e1-ace1-6da1f50246dc')) conflicts with persistent instance <IPAllocation at 0x89ac310>
14:16:43 <ihrachys> I should report it in LP
14:16:53 <ihrachys> I have a potential fix for that here: https://review.openstack.org/#/c/485328/
14:17:33 <ihrachys> there was a bug in the switching patch that was adding OVO object to sqlalchemy session to keep reference to the model, which obviously doesn't work
14:19:01 <manjeets_> I am also having a session.id expire issue with networkdhcpagentbinding ovo
14:19:11 <manjeets_> http://logs.openstack.org/52/370452/50/check/gate-neutron-python27-ubuntu-xenial/c1f6301/testr_results.html.gz
14:19:32 <ihrachys> I am still to test the patch, but lujinluo I would like to see you eyeballing it since you polished the switch patch. I hope I don't break anything with the fix.
14:20:02 <lujinluo> ihrachys, sure. will do
14:20:39 <manjeets_> I specified lazy in db model which fixed the constant_query_test but broke others
14:20:44 <ihrachys> manjeets_, is it because your agent model is not fetched via relationship?
14:20:58 <ihrachys> oh that's with lazy load?
14:21:24 <ihrachys> (well it's not really lazy; whoever came up with the name for sqlalchemy is guilty as hell)
14:21:45 <manjeets_> for some reason when I specify lazy to subquery or joined it loses its session
14:22:13 <manjeets_> it fails while expunging because hash doesn't match with session id
14:22:14 <manjeets_> https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/orm/session.py#L1625
14:23:57 <manjeets_> it just loses session_id not the entire session
14:24:02 <ihrachys> manjeets_, do we hit the model with .expunge() in _detach_db_obj before this other call?
14:24:12 <lujinluo> does this only happen in OVO patch? I think I have seen something similar but it happens to synthetic field.
14:25:03 <ihrachys> lujinluo, it is synthetic I believe. an object-field loaded via load_synthetic_db_fields
14:25:07 <ihrachys> right?
14:25:47 <manjeets_> something while loading synthetic field for second object
14:25:51 <manjeets_> https://github.com/openstack/neutron/blob/master/neutron/objects/base.py#L346
14:26:12 <lujinluo> yes, i think same place
14:26:14 <manjeets_> with in it it tries to load ovo and fails, on expunge
14:27:27 <ihrachys> manjeets_, I would look at the order of all expunge calls. maybe we first expunge the binding (that will probably expunge linked agent model too?), then the agent model
14:27:28 <manjeets_> but db query gets the right db_objs
14:28:55 <manjeets_> afair, I think order was same when I add lazy with when I remove it, but not 100% sure will check today
14:30:11 <ihrachys> manjeets_, do multiple bindings point to the same agent?
14:30:56 <ihrachys> if so, then get_objects() will expunge those agents (via bindings) over and over? [I am not sure expunge traverse recursively though]
14:31:33 <manjeets_> no I was able to see two agents one for each network
14:31:40 <manjeets_> in the tests atleast
14:32:46 <ihrachys> ok it doesn't seem like we can solve it during the meeting. :)
14:33:21 <manjeets_> once i check today I may hit on neutron channel today
14:33:28 <manjeets_> hit you**
14:33:42 <ihrachys> ok, just pick a harder stick
14:33:44 <ihrachys> :)
14:33:49 <manjeets_> lol
14:33:57 <ihrachys> I need it, really.
14:34:04 <ihrachys> haven't reviewed what I should have :)
14:34:15 <ihrachys> #topic OVO patches
14:34:22 <ihrachys> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db
14:34:30 <ihrachys> going top to bottom
14:35:05 <ihrachys> https://review.openstack.org/#/c/466237/ is router-port to port relationship. I saw lujinluo was planning to look at a better place for .refresh so I put it to wip.
14:35:07 <ihrachys> I hope that's fine
14:35:23 <lujinluo> sure. too many .refresh() in that patch.
14:35:57 <ihrachys> :) that's true. sqlalchemy is sometimes moody.
14:36:10 <ihrachys> next is https://review.openstack.org/#/c/482722/ (Integrate ovo in type_vlan cleanup)
14:36:29 <ihrachys> I think we wait for author reply on the suggestion to add test coverage
14:36:42 <ihrachys> next is https://review.openstack.org/#/c/407868/ (Integration of (Distributed) Port Binding OVO)
14:37:10 <lujinluo> hmm, i need a harder stick for this one too
14:37:25 <ihrachys> manjeets_, you have work to do man
14:37:49 <manjeets_> i need that too, haven't completed what I should have
14:37:57 <lujinluo> lol
14:38:05 <ihrachys> lujinluo, but seriously, you do a lot of parallel things, no wonder some things may slip from time to time, it's totally cool :)
14:38:29 <ihrachys> next is https://review.openstack.org/#/c/481972/ (FloatingIP to OVO)
14:38:49 <ihrachys> I think it's good, just waits for resolution on generator for unique constraints fix
14:39:01 <ihrachys> I will +2 when we solve the underlying on
14:39:02 <ihrachys> *one
14:39:07 <lujinluo> ack
14:39:43 <ihrachys> next to discuss is https://review.openstack.org/#/c/424154/ (RouterPort OVO integration)
14:40:03 <ihrachys> I see lujinluo respinned it
14:40:37 <ihrachys> I will review
14:41:07 <lujinluo> thanks! i am not sure how to deal with Port as a synthetic field so I used .db_obj
14:41:21 <lujinluo> please review and comment
14:41:44 <ihrachys> yeah, I see. btw those comments should probably be in the format of TODO(lujinluo) ...text... so that we can grep for TODO/name later
14:41:48 <ihrachys> I will
14:42:09 <lujinluo> ah, I see. will add them in next PS
14:42:10 <ihrachys> next is network dhcp agent binding but I discussed that before
14:42:26 <ihrachys> next is dvr mac address: https://review.openstack.org/#/c/304873/
14:42:34 <ihrachys> it has +2, need to get another one
14:42:44 <ihrachys> probably from Kevin since he did review it in the past
14:48:17 <ihrachys> woa, I continued the meeting in neutron channel lol
14:48:22 <ihrachys> I am pathetic
14:48:25 <ihrachys> anyhow
14:48:31 <ihrachys> #topic Open discussion
14:48:47 <ihrachys> note that we are approaching feature freeze dates at which point we may hit a temporary lock on new patch merges, usually taking about 2 weeks.
14:48:52 <lujinluo> wow, i was waiting
14:49:06 <ihrachys> lujinluo, I was wondering why no one replies :p
14:49:20 <ihrachys> I think freeze is ~month from now
14:49:23 <ihrachys> checking calendar
14:49:44 <lujinluo> i think it is the last week of July
14:49:49 <ihrachys> yeah, first RC is Aug 07 - Aug 11
14:50:06 <lujinluo> aha, bad memory :-x
14:50:18 <ihrachys> well feature freeze is indeed the last week of July
14:50:25 <ihrachys> but RC is one week later
14:50:33 <ihrachys> some time there, we will be locked
14:50:53 <ihrachys> it's usually till RC that we have ability to cautiously land some patches
14:51:13 <lujinluo> ok..
14:52:19 <ihrachys> ok let's wrap it up
14:52:25 <ihrachys> thanks everyone
14:52:30 <ihrachys> #endmeeting