15:00:55 <manjeets> #startmeeting weekly meeting
15:00:55 <odl_meetbot> Meeting started Mon Apr 23 15:00:55 2018 UTC.  The chair is manjeets. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:00:55 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:55 <odl_meetbot> The meeting name has been set to 'weekly_meeting'
15:00:56 <mpeterson> manjeets will chair today
15:00:59 <mpeterson> there we go :)
15:01:01 <jhershbe> yamahata, I'm happy to talk in an hour
15:01:08 <manjeets> #topic Agenda
15:01:11 <yamahata> okay, in an hour.
15:01:28 <jhershbe> yamahata, I'm going to drop for an hour. I'll ping you in like an hour
15:01:34 <manjeets> we'll start with action items from last meeting
15:02:10 <manjeets> action item 1st to review the ovn document for handling resources with revision number
15:02:40 <manjeets> i reviewed, sounds like a good idea but I have a question
15:03:06 <manjeets> mpeterson, will the verification logic reside in neutron or respective projects ?
15:03:14 <mpeterson> manjeets: wanna do this in topic agenda or should you move the topic?
15:03:32 <mpeterson> manjeets: what verification logic? there are different parts to it
15:03:43 <manjeets> #topic action items from last meeting
15:04:03 <mpeterson> manjeets: some parts are project dependant and some are generic
15:04:05 <manjeets> mpeterson, revision number verification for resource
15:04:24 <mpeterson> manjeets: those in the library
15:04:56 <mpeterson> let me share with you the latest version I have of the spec
15:05:08 <mpeterson> https://gist.github.com/mpeterson/1a9f81f68401b0e58579c38c01dd0891
15:05:30 <manjeets> thanks mpeterson, i'll read this one
15:05:57 <manjeets> mpeterson, the thing is it need to access the revision number of resource from backend database
15:05:59 <mkolesni> hi!
15:06:00 <mpeterson> you can read in https://gist.github.com/mpeterson/1a9f81f68401b0e58579c38c01dd0891#interface
15:06:17 <mpeterson> that it has more details as how you interact with it and the expected behaviors
15:06:43 <mpeterson> manjeets: what you are asking should be explained in sync_resource
15:08:34 <manjeets> ok ! i'll read details after this meeting, so with this will the journaling mechanism be deprecated ?
15:08:37 <manjeets> hi mkolesni
15:08:46 <mkolesni> yes
15:09:54 <manjeets> I am still not clear then how the lost transactions to ODL NB will be recovered ?
15:10:08 <manjeets> if there's no journaling
15:10:11 <mkolesni> what lost transactions?
15:10:15 <poothia__> i guess we should keep good parts of both!!
15:10:44 <poothia__> in case of failure, we can still handle situaltion like we do in journaling
15:10:58 <manjeets> mkolesni, the communication between n-odl and ODL NB
15:11:11 <mkolesni> but this covers it
15:11:17 <mkolesni> im not sure what u mean?
15:11:20 <mpeterson> manjeets: if it's a creation it remains in RN=-1
15:11:54 <mpeterson> manjeets: if it's an update you'll notice a RN that's different between standardattributes and the table the proposal introduces
15:12:19 <mpeterson> manjeets: therefore you can run a periodic table that fixes inconsistencies
15:12:39 <mkolesni> indeed that is covered in the spec afaict
15:12:41 <mpeterson> manjeets: more details at https://gist.github.com/mpeterson/1a9f81f68401b0e58579c38c01dd0891#utility-functions
15:13:01 <mkolesni> i havent finished going over all of it yet
15:16:13 <manjeets> so one more question for checking RN in n-odl, will it be asking ODL client every time ? or there will new field in journaltable in neutron ?
15:17:14 <mpeterson> manjeets: that check is transparent to the driver, as it is done by sync_resource
15:17:30 <mkolesni> no it shouldnt talk to odl each time
15:17:41 <mkolesni> it has its own bookkeeping
15:18:20 <mpeterson> manjeets: and worst case scenario, if an update with a lower RN number is pushed to n-odl nb then n-odl nb would return an exception
15:18:34 <mpeterson> manjeets: AFAIK there is a bug for that, since that's not happening now
15:18:38 <mpeterson> mkolesni: right?
15:18:39 <mkolesni> mpeterson, or silently ignore it, thats also fine
15:18:54 <mpeterson> mkolesni: true that
15:19:03 <manjeets> ok, silently ignoring is fine I guess
15:19:10 <mkolesni> mpeterson, right now as jhershbe said if both have a RN and the one in MDSAL is newer it will ignore the  update
15:19:27 <mpeterson> which makes sense
15:19:50 <mkolesni> indeed
15:20:50 <manjeets> suppose there's a lost transaction (mean n-odl sends resource operation request to ODL NB) which get losts for some reason, without journaling how that sync would work
15:20:52 <manjeets> ?
15:21:20 <mpeterson> manjeets: it only updates the RN on success from n-odl
15:22:54 <manjeets> mpeterson, hmm sounds little tricky
15:23:16 <mpeterson> manjeets: how's that different from the current implementation?
15:23:20 <poothia__> mpeterson:
15:23:51 <manjeets> mpeterson, like sync thread keep syncing resources from journal table with ODL
15:24:23 <poothia__> mpeterson: what if it is in the success state in ODL too but it can't be communicate to n-odl that... what will happen then?
15:24:44 <mpeterson> manjeets: full sync you mean?
15:25:10 <mkolesni> huh?
15:25:15 <manjeets> sort of yes
15:25:34 <mpeterson> poothia__: you mean the change impacted in n-odl nb but the communication got cut off when returning the OK state?
15:25:45 <poothia__> yes
15:26:20 <mkolesni> unlikely but then it will simply resend it in the maintenance thread
15:26:27 <mkolesni> and the n-odl should ignore that
15:26:39 <mpeterson> and then the RN is updated
15:26:51 <mpeterson> so no problem there
15:27:48 <manjeets> mpeterson, so are you drafting a spec for neutron right ?
15:28:00 <mpeterson> manjeets: correcty
15:28:03 <mpeterson> -y
15:28:34 <manjeets> ok, looking forward to that too, but I guess it will be similar to link you posted today
15:28:39 <mpeterson> manjeets: the one I sent you... which is complete but waiting for corrections
15:28:51 <manjeets> mpeterson, thats what i thought
15:28:54 <manjeets> cool !
15:29:05 <manjeets> lets move on to next action item
15:29:11 <mkolesni> mpeterson, maybe itll be easier to review in a gdoc?
15:29:20 <mkolesni> then we can propose fixes also
15:29:45 <manjeets> everyone was expected to review full sync enabling patch by rajivk
15:29:51 <mpeterson> mkolesni: yes, probably... I'll do that ...
15:30:06 <mkolesni> mpeterson, cool
15:30:15 <manjeets> sorry I had a tight schedule was at event for 3 days so couldn't cover all action items
15:30:27 <mkolesni> mpeterson, u can give us permission to comment, then we can also make suggestions which u can approve/reject
15:30:28 * manjeets takes a note to review it this week
15:30:53 <mpeterson> mkolesni: the only problem I see is that it does not support RST, does it?
15:30:56 <mkolesni> manjeets, no worries we actually had half a week holidays in israel so not much got done either
15:31:35 <mkolesni> mpeterson, it wont render it, but for initial drafting i suspect it will be more efficient
15:32:02 <manjeets> ok these were two main action items from last meeting ?
15:32:08 <manjeets> did I miss anything ?
15:34:14 <manjeets> and engine facade adoption by mpeterson
15:34:37 <manjeets> #action to review fullsync patch
15:35:48 <manjeets> #actionitem to review engine facade adoption
15:36:14 <manjeets> mpeterson, mkolesni what's the tag for action items ?
15:36:43 <manjeets> ohk its #action
15:36:51 <manjeets> lets move on
15:36:55 <manjeets> #topic bugs
15:37:03 <mkolesni> i dont think it notifies u it just parses it
15:37:16 <manjeets> any notable bugs we should have concern for ?
15:37:25 <manjeets> mkolesni, oh got it
15:37:28 <mpeterson> #info version to edit for the v3 spec d/1gjZGqPGSkd1SaTBeBLmejLZI9dZ3S6ETaVrC51rHJM4/edit
15:37:46 <mpeterson> #undo
15:38:11 <mpeterson> #info version to edit for the v3 spec https://docs.google.com/document/d/1RjgshXGAtSQYw1B5bYfJVRBwwSu1oRJvN8bRZnssOfI/edit?usp=sharing
15:38:31 <mkolesni> mpeterson, it says 'request access'
15:38:43 <manjeets> i guess git is better
15:38:46 <mpeterson> manjeets: try again :)
15:39:00 <mpeterson> mkolesni: I mean
15:39:10 <manjeets> all m's
15:39:22 <mpeterson> haha yeah
15:39:38 <manjeets> alright do we have any bugs to discuss ?
15:39:57 <mkolesni> mpeterson, worx
15:40:30 <mkolesni> mpeterson, u need to give us access to comment tho
15:40:48 <mpeterson> mkolesni: now? :)
15:41:03 <mpeterson> manjeets: there hasn't been any activity whatsoever since last week, sadly...
15:41:27 <manjeets> ohk, mean we have a lot to do this week
15:41:53 <mkolesni> mpeterson, yep now worx
15:41:59 <manjeets> #topic open mic
15:42:06 <mpeterson> mkolesni: yey! I don't use google in case you haven't noticed :P
15:42:25 <mpeterson> manjeets: yeah! I wanna see action! :)
15:43:05 <manjeets> cool ! anything else or we can adjourn the meeting ?
15:43:19 <poothia__> mkolesni:  i wanted to ask if https://blueprints.launchpad.net/networking-odl/+spec/save-data-as-json is still required?
15:43:48 <mkolesni> poothia__, no lets close it as we intent to work on v3 driver
15:44:04 <mkolesni> mpeterson, u learn something new then :)
15:44:49 <poothia__> mkolesni: ok...
15:45:25 <poothia__> manjeets:  when are we planning bug triage meeting ?
15:46:01 <manjeets> mkolesni, how about next week spending some time on bug list ?
15:46:12 <mkolesni> ok sure
15:46:24 <manjeets> or blueprint list as well so that we cleanup
15:46:57 <mpeterson> yeah, and perhaps anyone has a good idea for poothia__ to mess around with n-odl so he can learn?
15:47:03 <manjeets> #info discuss buglist/blueprint list in next week's meeting
15:48:22 <manjeets> mpeterson, will be the chair next week, incase we forget poothia__ will remind us ?
15:48:44 <poothia__> manjeets:  for sure
15:48:53 <manjeets> anything else ?
15:49:08 <mpeterson> nope
15:49:35 <manjeets> thank you everyone have a great week
15:49:46 <manjeets> #endmeeting