16:10:28 <flaviof> #startmeeting neutron northbound
16:10:28 <odl_meetbot> Meeting started Fri Nov  6 16:10:28 2015 UTC.  The chair is flaviof. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:10:28 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:10:28 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
16:10:41 <flaviof> #chair john_a_joyce MisterS
16:10:41 <odl_meetbot> Current chairs: MisterS flaviof john_a_joyce
16:11:19 <flaviof> as mentioned by john_a_joyce: "there are three main things:  get the rewrite merged, get a test harness together to test it,  figure out a sync strategy"
16:11:41 <flaviof> as mentioned by flaviof: "I think the seqnum solution is not going to cut it"
16:12:01 <john_a_joyce> with respect to merge - Arvind had a few changes to do based on the discussion around database locking
16:12:25 <john_a_joyce> +1 to the seq num not cutting it
16:12:49 <flaviof> wrt to "row locking", is that related to "rewrite merged" or "sync" ?
16:13:06 <john_a_joyce> rewrite merged
16:13:09 <flaviof> ack
16:13:21 <flaviof> are these changes in gerrit?
16:13:39 <john_a_joyce> yes
16:13:53 <john_a_joyce> searching for them
16:14:00 <flaviof> #link https://review.openstack.org/#/c/222409/ Opendaylight driver refactor to handle out of sync issues
16:14:19 <flaviof> looks right?
16:14:57 <rcurran> flaviof, (sorry came in late) yes, that's the one
16:14:58 <john_a_joyce> yes - that is correct
16:15:17 <flaviof> np
16:15:53 <john_a_joyce> so other than the row locking issue discussed in Tokyo - are there any other concerns with that change set?
16:16:06 <flaviof> k, I'd definitely would propose we defer merging it till after Isaku is back.
16:16:30 <john_a_joyce> sure - Arvind hasn't updated it yet anyway
16:16:49 <john_a_joyce> to address the row locking
16:16:58 <flaviof> john_a_joyce : cool!
16:17:22 <flaviof> is there any way that changeset can be tested via tox?
16:17:39 <john_a_joyce> ok - so unless some one has a concern I will check with Arvind about updating then we can try to merge when Isaku is back
16:17:46 <rcurran> yes, https://review.openstack.org/#/c/227941/
16:17:57 <john_a_joyce> sure - the unit tests are there
16:18:03 <flaviof> john_a_joyce +1
16:18:10 <flaviof> rcurran thanks
16:18:28 <john_a_joyce> they just won't find the type of race conditions that got us into this mess to begin with
16:20:37 <john_a_joyce> for the testing we will have to wait until Isaku's back as well, his team was taking the lead for that.
16:22:55 <john_a_joyce> so that leaves full sync - to discuss
16:23:57 <flaviof> john_a_joyce agree. on that topic, I think it can be further split into 2 parts: 1) detect sync is needed and 2) doing the sync itself.
16:23:57 <john_a_joyce> I think the concensus is that we should introduce a new API that can be polled by one of the sides
16:24:07 <john_a_joyce> sure
16:24:35 <john_a_joyce> I suspect we will find doing the sync can just be minor extensions to the new journal scheme
16:24:51 <flaviof> john_a_joyce agree
16:24:56 <john_a_joyce> detecting the sync is need is the oen we haven't progesses much on
16:25:29 <john_a_joyce> so what do we pass across the API to determine things are not out of sync?
16:25:34 <flaviof> yup. we went back and forth on the seqnum idea, which is definitely not too sound; and the create a hash idea
16:26:15 <john_a_joyce> would a HASH of all the resource IDs be sufficient?
16:27:17 <flaviof> heh, if the approach is to have a full sync (not delta) that may be all that is needed
16:27:46 <john_a_joyce> flaviof +1
16:28:47 <flaviof> does the neutron native objs give us a hash for free? or is that something odl will need to 'bolt on'?
16:28:54 <john_a_joyce> but for efficiency we would want a hash function that provides the dame result regardless of the order the IDs are hashed
16:30:15 <john_a_joyce> let me say that different - the hash function MUST be independent of order - because we can't guarantee object order across multiple server processes
16:31:08 <john_a_joyce> for efficiency it would be nice that the function can also be incrementally calculated as objects are added and deleted
16:32:42 <john_a_joyce> so I think the next step is to bring a proposal that describes the hash function
16:33:34 <flaviof> john_a_joyce make sense. it should account for versioning or a way of purge the journal as obj changes
16:33:54 <flaviof> obj changes (attribs added/removed)
16:36:39 <john_a_joyce> I will try to have a proposal for next week to share
16:36:57 <john_a_joyce> unless someone else already has some thoughts in the works
16:37:19 <flaviof> john_a_joyce sounds good; no I have not thought about this any further.
16:38:31 <vthapar> I have one question on this, would these sync changes be restricted to just ML2 driver?
16:38:42 <flaviof> so, in summary: see about wrapping up and merge db journal changes+tests; and then 'rehash' how we detect out of sync
16:39:16 <vthapar> or is the plan to make it sort of framework that can be used for rest of code like l3, lbaas, bgpvpn, lwgw [which are coming up]
16:39:26 <flaviof> vthapar definitely not; l3, sec groups, vpn... all need to be accounted for as well and they are not ml2.
16:39:54 <vthapar> okay, just wanted to be sure.
16:40:19 <flaviof> in brief, anything that networking-odl tell odl needs to be accounted under this scope
16:40:21 <flaviof> all agree?
16:40:32 <john_a_joyce> rcurran has a change set in progress for L3
16:40:32 <rcurran> flaviof, so you don't think we should use this journal infrastruture for other neutron events?
16:40:37 <rcurran> l3?
16:41:06 <john_a_joyce> flabiof +1
16:41:15 <rcurran> flaviof, i'm not referring to the hash discussion. just the new interface from neutron -> ODL controller
16:41:16 <john_a_joyce> flaviof +1
16:41:26 <flaviof> rcurran i'm hoping that the journal is not only servicing ml2, but all others
16:41:37 <rcurran> flaviof, ok
16:42:22 <rcurran> flaviof, misread your first comment :-)
16:42:54 <flaviof> rcurran np
16:43:40 <flaviof> anything else we want to talk about? otherwise we can wrap it for today
16:46:59 <john_a_joyce> not from me
16:47:29 <flaviof> #topic cookies
16:47:33 <flaviof> #endmeeting