15:01:41 <yamahata> #startmeeting neutron_northbound
15:01:41 <odl_meetbot> Meeting started Mon Oct  2 15:01:41 2017 UTC.  The chair is yamahata. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:01:41 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:41 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
15:01:59 <yamahata> seems too slow. anyway let's start
15:02:03 <yamahata> #chair mkolesni
15:02:03 <odl_meetbot> Current chairs: mkolesni yamahata
15:02:13 <yamahata> #topic agenda bashing and roll call
15:02:17 <mkolesni> #info mkolesni
15:02:21 <yamahata> #info yamahata
15:02:22 <rajivk_> #info rajivk
15:02:35 <yamahata> #chair rajivk_
15:02:35 <odl_meetbot> Current chairs: mkolesni rajivk_ yamahata
15:02:57 <yamahata> Do we have any topics other than usual ones?
15:03:15 <mkolesni> yes
15:03:35 <yamahata> mkolesni:   what topic do you have?
15:03:50 <mkolesni> fyi we have upcoming shutdown due to holidays, i will be back on oct 15th starting from this Wed
15:04:09 <mkolesni> so 4-15 im not working
15:04:23 <yamahata> so you'll skip the meeting on Oct 9.
15:04:29 <mkolesni> yes
15:04:53 <yamahata> there is ODL DDF on Oct 9-10. so I'll also skip the meeting.
15:05:04 <yamahata> Let's cancel it next week.
15:05:08 <mkolesni> right
15:05:56 <yamahata> anything else?
15:06:01 <mkolesni> i saw today gate is broken due to zuul v3 migration
15:06:24 <mkolesni> we should focus on that before anything else
15:06:57 <yamahata> Yeah. There was an announcement on it. We need to fix it if any.
15:07:34 <mkolesni> i saw first that clones from tools/tox_install.sh should probably move toi requirements
15:07:42 <mkolesni> to*
15:07:50 <mkolesni> otherwise basic jobs fail
15:08:01 <mkolesni> also legacy jobs fail but havent looked at that yet
15:08:43 <mkolesni> so if you have time please look at it
15:08:45 <yamahata> let's discuss it after routine topics.
15:08:51 <mkolesni> if not ill try to do my best tomorrow
15:08:55 <mkolesni> ok
15:08:56 <yamahata> #topic Announcements
15:09:23 <yamahata> #info ODL DDF will take place Oct 9, 10. So the meeting next week will be skipped.
15:09:34 <yamahata> Is there any announcement?
15:10:08 <yamahata> #info openstack summit Sydney will be held November 6-8, 2017.
15:10:14 <yamahata> There will be forum sessions.
15:10:26 <yamahata> Unfortunately I won't attend it though.
15:10:34 <mkolesni> i wont be there either
15:10:46 <yamahata> any other announcement?
15:11:04 <yamahata> Oh one last annoucement
15:11:12 <yamahata> #info ODL Nitrogen has been released finally.
15:11:20 <yamahata> Now Oxygen cycle is starting.
15:11:38 <mkolesni> nice
15:11:52 <yamahata> #topic action items from last meeting
15:12:03 <yamahata> I suppose we don't have any since we didn't have meeting last week
15:12:08 <yamahata> #topic Queens/Oxygen planning
15:12:20 <yamahata> Ok, now we're discussing zuulv3 issue
15:12:30 <yamahata> #info now mkolesni is looking into it.
15:12:42 <yamahata> Also I'll also look into it.
15:13:15 <yamahata> mkolesni: any other additional info to share?
15:13:24 <mkolesni> as i said, i saw first that clones from tools/tox_install.sh should probably move to requirements
15:13:40 <mkolesni> to fix the basic jobs which are global
15:14:14 <yamahata> #link http://lists.openstack.org/pipermail/openstack-dev/2017-September/122630.html [openstack-dev] [all][infra] Zuul v3 migration update
15:14:26 <yamahata> #link http://lists.openstack.org/pipermail/openstack-dev/2017-September/122841.html [openstack-dev] [devstack] zuulv3 gate status;	LIBS_FROM_GIT failures
15:15:00 <yamahata> #link https://docs.openstack.org/infra/manual/zuulv3.html Zuul v3 Migration Guide
15:15:33 <yamahata> mkolesni: thanks.
15:15:43 <mkolesni> is there a reason to clone all of them rather than have them in test-requirements for example?
15:16:17 <mkolesni> or maybe were just cloning them wrong and theres a right way to do this with zuul v3
15:17:34 <yamahata> We followed how neutron does.
15:18:01 <mkolesni> i didnt see such cloning in neutron now
15:18:04 <yamahata> Now neutron project dropped tox_install.sh.
15:18:08 <mkolesni> also their gate works
15:18:19 <mkolesni> we should probably align then
15:18:56 <yamahata> c25ece63bd8eefac4520d98ed7469ee446f4f59c change it.
15:20:36 <yamahata> mkolesni: can you take care of it?
15:20:47 <mkolesni> i will look into it tomorrow
15:20:52 <yamahata> Great.
15:21:03 <mkolesni> but as i said on wed im off to holidays
15:21:18 <mkolesni> so if i cant find it tomorrow youll have to take care of it
15:21:18 <yamahata> I see. so you have only tuesday.
15:21:22 <mkolesni> yes
15:21:27 <yamahata> Ok, got it.
15:21:29 <mkolesni> only tomorrow left
15:23:16 <yamahata> ajivk_ do you have any updates?
15:23:48 <rajivk_> yamahata, i wanted to discuss a few things
15:24:00 <yamahata> yeah, please go ahead
15:24:29 <rajivk_> During recovery, why do we need to fetch resource from db?
15:24:43 <rajivk_> if we already have a journal entry, is not it enough?
15:25:00 <mkolesni> no in recovery its failed rows
15:25:11 <mkolesni> meaning the journal entry is already out of sync
15:25:24 <mkolesni> could be even out of sync with neutron's state itself
15:25:42 <mkolesni> since failed rows dont come into account of dependency calculation
15:26:08 <rajivk_> Could you please suggest a scenario?
15:26:42 <mkolesni> yes for example delete which fails because of 404
15:26:51 <mkolesni> entry will move to failed
15:27:12 <mkolesni> sorry this actually doesnt matter
15:27:30 <mkolesni> but for example if update or create fails, then the resource was deleted from neutron
15:27:36 <mkolesni> no need to handle it anymore
15:28:00 <mkolesni> or we might need to delete it from odl if its there but not in neutron
15:28:15 <mkolesni> so its all covered by recovery
15:28:36 <rajivk_> so, update and create fails at odl side then neutron still contains the journal
15:28:43 <mkolesni> yes
15:28:50 <rajivk_> and journal contains failed entry
15:29:00 <rajivk_> so how does fetching from db is needed
15:29:10 <rajivk_> we keep on trying with the same journal entry
15:29:21 <mkolesni> but its stale
15:29:29 <rajivk_> if an update arrive at neutron side on failed resource then journal is created for the same
15:29:36 <mkolesni> the resource couldve changed
15:29:58 <rajivk_> it fails definitely due to parent resource but journal entry exist
15:30:04 <mkolesni> new entry is created but old failed entry is still there and will be picked up by the recovery
15:30:07 <rajivk_> how it could have changed
15:30:25 <mkolesni> what do you mean?
15:30:27 <rajivk_> without having journal entry for the new update?
15:30:41 <rajivk_> my questions is
15:30:42 <mkolesni> you will have it, or not, it doesnt matter
15:30:55 <rajivk_> let's take a scenario
15:31:01 <mkolesni> the fact is the failed entry is considered stale
15:31:06 <mkolesni> you cant rely on it
15:31:21 <rajivk_> How that's the point
15:31:28 <rajivk_> because we will have one more entry for update
15:31:33 <mkolesni> it doesnt matter if theres a newer entry or not
15:32:24 <mkolesni> so what about the new entry? maybe it was processed already before the recovery kicks in
15:32:25 <rajivk_> You want to say if a resource creation fails then we have stale entry at ODL side?
15:32:37 <mkolesni> no
15:32:42 <rajivk_> it is not possible because parent resource does not exist
15:32:46 <mkolesni> the journal entry, which is failed, contains stale data
15:32:48 <rajivk_> so it is bound to fail
15:33:02 <mkolesni> im not sure what youre talking about
15:33:10 <mkolesni> you have for example update network
15:33:13 <mkolesni> it fails
15:33:22 <rajivk_> okay
15:33:26 <mkolesni> then this journal entry moves to failed state
15:33:28 <mkolesni> right?
15:33:41 <rajivk_> yes
15:33:45 <mkolesni> then another update of same network, succeeds
15:34:00 <rajivk_> okay
15:34:03 <mkolesni> then this journal entry is completed, or deleted, it doesnt matter
15:34:09 <mkolesni> then recovery runs
15:34:13 <mkolesni> picks up old update
15:34:26 <mkolesni> now you want to execute it and update network to a stale state?
15:35:04 <mkolesni> you have to read the network again, you cant trust the data in the failed entry
15:35:59 <rajivk_> hmm, got it.
15:36:33 <rajivk_> because we don't have good way to find among two entry, which to apply first and then second
15:36:51 <mkolesni> yes
15:37:33 <rajivk_> Got it. i am getting a lot of ifs now in the recovery and full sync
15:38:04 <mkolesni> a lot of ifs?
15:38:55 <rajivk_> Different drivers of ODL are implemented with some difference then the way neutron understand.
15:39:08 <mkolesni> ok
15:39:37 <rajivk_> for example, l2gateway-connection is used and neutron uses l2-gateway-connection
15:39:56 <rajivk_> neutron uses different attribute to store gatway id and odl understands different
15:40:13 <rajivk_> bgpvpn driver we don't have network assoc and router assoc in odl
15:40:18 <mkolesni> ok
15:40:19 <rajivk_> but they are update operations on odl
15:40:20 <yamahata> Do you mean inconsistency of naming between odl and neutron?
15:40:26 <rajivk_> yes
15:40:36 <rajivk_> and attributes name as well
15:40:49 <rajivk_> and the way neutron and odl thinks about the resources
15:41:09 <rajivk_> driver handle it, we should not handle them in recovery and full sync again
15:41:54 <rajivk_> what if for create during recovery, i use precommit of driver, it does all manipulation, i am thinking about it and complexity
15:42:03 <rajivk_> just wanted to have your opinion
15:43:09 <mkolesni> you have a poc for this?
15:43:27 <mkolesni> if its simpler go ahead
15:43:35 <mkolesni> i suspect it wont be but maybe it will
15:43:49 <rajivk_> not yet.
15:44:10 <mkolesni> ok
15:44:24 <rajivk_> yamahata, can you think of complexity or the problem we can encounter?
15:44:39 <yamahata> right now I don't see big one.
15:44:55 <yamahata> If you have poc patch, we can discuss it based on poc.
15:45:38 <yamahata> In ideal world, there shouldn't be naming inconsistency. In reality we can't avoid it given the current situation.
15:45:42 <rajivk_> okay, i will try a PoC patch for it.
15:46:09 <yamahata> some adaptation layer would be inevitable probably.
15:46:25 <rajivk_> between which two layers
15:47:52 <rajivk_> regarding this https://review.openstack.org/#/c/504297/
15:48:14 <yamahata> new lib/neutron patch?
15:48:26 <rajivk_> yamahata, yes, do we want to keep neutron legacy and neutron both together?
15:48:44 <yamahata> Eventually neutron legacy will be removed.
15:48:53 <yamahata> During transition we would need to keep both.
15:49:20 <rajivk_> okay
15:49:39 <rajivk_> now, their are many workaround need to cleanup it, once gate job are working
15:49:40 <yamahata> Once we're confident with new lib/neutron, we can remove legacy one.
15:50:39 <rajivk_> okay, that's all, i wanted to discuss
15:50:46 <yamahata> Great.
15:50:59 <yamahata> From me, my concern is ODL 404 bug.
15:51:08 <yamahata> I'm not sure anyone is actively working on it or not.
15:51:16 <mkolesni> not that i know
15:51:53 <yamahata> Okay. that's unfortunate.
15:52:03 <yamahata> and we have new 5 bug report since PTG.
15:52:09 <yamahata> 2 are already in progress.
15:52:37 <yamahata> that's all I wanted to share.
15:52:46 <yamahata> #topic open mike
15:52:48 <mkolesni> ok
15:52:51 <yamahata> anything else?
15:52:56 <yamahata> otherwise I'll give you back 8mins
15:53:13 <mkolesni> btw next week mpeterson should be working Sun-Tue so you guys can ping him if you need something
15:53:30 <yamahata> okay.
15:53:40 <yamahata> Thank you everyone.
15:54:00 <rajivk_> thanks Mike, Yamahata
15:54:02 <yamahata> #topic cookies
15:54:07 <yamahata> #endmeeting