16:18:25 <abhijitkumbhare> #startmeeting OFP IRC meeting May 21
16:18:25 <odl_meetbot> Meeting started Thu May 21 16:18:25 2015 UTC.  The chair is abhijitkumbhare. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:18:25 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:18:25 <odl_meetbot> The meeting name has been set to 'ofp_irc_meeting_may_21'
16:18:38 <tbachman> #info tbachman
16:18:40 <abhijitkumbhare> IRC only - don't have a webex
16:18:58 <ttkacik> I could provide webex if needed
16:19:04 <abhijitkumbhare> Sorry my IRC seemed to show only half of you
16:19:10 <abhijitkumbhare> we can use a webex
16:19:30 <abhijitkumbhare> can you share a webex ttkacik
16:19:46 <ttkacik> give sec
16:19:50 <abhijitkumbhare> thx
16:20:56 <ttkacik> https://cisco.webex.com/join/ttkacik
16:21:00 <abhijitkumbhare> OK
16:23:03 <abhijitkumbhare> webex is taking a long time for me to join
16:23:24 <kot-begemot> This is a slightly different version, it will be pulling a few new jars
16:23:33 <ttkacik> we are waiting for you
16:26:55 <kot-begemot> FYI: the meeting moved to webex https://cisco.webex.com/join/ttkacik
16:27:20 <colindixon> kot-begemot: I’m assuming nobody is taking notes in IRC then?
16:28:23 <kot-begemot> A few more slots on the webex, please join
16:28:28 <abhijitkumbhare> Will be taking IRC notes
16:28:36 <abhijitkumbhare> But I will add a few chairs
16:29:01 <abhijitkumbhare> #chair tbachman michal_rehak colindixon
16:29:01 <odl_meetbot> Current chairs: abhijitkumbhare colindixon michal_rehak tbachman
16:29:07 <tbachman> :)
16:29:27 <abhijitkumbhare> #topic Decision regarding He / Li
16:31:48 <tbachman> #info michal_rehak says throughput test mode has lower performance than Helium code base, but the new design has many other better properties
16:32:06 <tbachman> #info michal_rehak says the latency numbers are better, and statistics collection from architectural perspective look better
16:32:18 <tbachman> #info michal_rehak asks for arguments for going with Helium vs. Lithium
16:32:36 <tbachman> #info kot-begemot says the hashing codes are a big issue — thinks code shouldn’t be frozen in this state
16:33:12 <tbachman> #info vishnoianiol asks jamoluhrsen and LuisGomez from an integration test perspective how things look
16:33:26 <tbachman> #info jamoluhrsen says he doesn’t like the way it looks with the Lithium code base — too many failures
16:33:51 <tbachman> #info rovarga says the issue here is the version of OVS (2.0) being used in integration — has too many issues, and should be using 2.3.0+
16:34:17 <tbachman> #info rovarga says the new plugin is good a flushing out the errors in OVS that weren’t detected by the old ones
16:34:38 <rovarga> #info my understanding is that this is related to group/meters, I think
16:34:45 <tbachman> #info jamoluhrsen says if that’s the case, then we need to get the CI environment updated ASAP
16:34:54 <colindixon> so, “doesn’t work with OVS 2.0” sounds like it’s a bug not a feature
16:34:54 <tbachman> anyone have a link?
16:34:59 <tbachman> rovarga: thx!
16:35:26 <jamoluhrsen> if the explanation is correct, it makes sense.
16:35:30 <tbachman> #info ttkacik says the old plugin has issues with statistics and working with groups
16:36:00 <tbachman> #info rovarga says there is an issue asking for an upgrade of OVS from Peter
16:36:49 <tbachman> #info jamoluhrsen asks if with the Helium code base, the plugin is incorrectly dealing with a broken vswitch, which is why our tests are passing
16:37:19 <tbachman> #info jmedved asks if jamoluhrsen can verify the behavior with the newer version of OVS (2.3)
16:37:32 <tbachman> #action jamoluhrsen to verify new plugin with OVS 2.3
16:37:43 * tbachman missed vishnoianil’s question
16:38:25 <tbachman> #info kot-begemot says there is an issue between He and Li, the original match converter was flattened and unrolled. In Lithium, it’s all flat — long sequence, so patches won’t apply cleanly across both
16:39:08 <tbachman> #info kot-begemot says the only places where the prefixes have effect in Helium are the match conversion and action conversion; In Lithium, it also affects the hashing code.
16:39:20 <tbachman> #info rovarga asks if this affects IPv6 compliance, or is it a separate issue
16:39:37 <tbachman> #info kot-begemot says that the moment you apply the v6 conversion to Lithium, you have to fix the hashing code too
16:40:18 <tbachman> #info rovarga says essentially that this means the IPv6 hashing code needs to be fixed in order to correctly hash the normalized IPv6 addresses
16:40:28 <tbachman> exponential backoff ;)
16:40:55 * tbachman missed that last one
16:41:19 <colindixon> yes, it’s related to the IPv6 functionality, it means that equality will not work
16:41:29 <tbachman> #info rovarga says this seems like two interspersed problems, and instead of tackling each one individually, we’re conflating the two
16:41:45 <tbachman> #info kot-begemot says that with the current design of the hashing code, it’s difficult to do a fix for v6
16:42:21 <tbachman> #info kot-begemot says the way it’s done currently results in a very bad hash, which creates more work and is not reusable if we fix the hashing computation
16:42:55 <tbachman> #info rovarga says if we take the entire hashing and just remove it, it’s not strictly required for the Lithium code base
16:43:00 <tbachman> #info rovarga asks if that solves the IPv6 issues
16:43:18 <tbachman> #info rovarga says we’re discussing two things — normalization of IPv6 and a hashing function in one of the code bases
16:43:43 <tbachman> #info vishnoianil says there are two separate issues, but they have overlapping boundaries
16:44:17 <tbachman> #info kot-begemot says it’s a side-effect of how v6 addresses are represented; once you normalize them and apply compression correctly, hash would result in the same value across a large set of them
16:44:32 <tbachman> #info rovarga asks if that means the code will not work correctly?
16:44:50 <tbachman> #info kot-begemot says hash means at least not putting everything in the same hash bucket — becomes a performance bottleneck
16:45:04 <tbachman> #info rovarga asks if it affects correctness or not
16:45:16 <tbachman> #info kot-begemot says if we take it out and don’t use it, then most of the fixes are done
16:45:31 * tbachman hopes he’s representing this correctly
16:45:44 <tbachman> #info rovarga asks if solving this problem allows us to cut the branch and move forward
16:46:09 <tbachman> #info kot-begemot says if we take out the hash code and acceleration benefit from it, what’s the difference between the Helium and Lithium branches — what’s the benefit
16:46:22 <tbachman> #info rovarga asks for design documents to look at to compare
16:46:36 <michal_rehak> https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Design_Proposal
16:46:43 <tbachman> #info rovarga says if you look at the design differences, the benefits should be self-evident
16:46:44 <abhijitkumbhare> #link https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Design_Proposal
16:46:48 <tbachman> #lundo
16:46:52 <abhijitkumbhare> #link https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Design_Proposal
16:47:01 <tbachman> #undo
16:47:01 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x1b886d0>
16:47:02 <tbachman> #undo
16:47:02 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x1b88990>
16:47:14 <tbachman> #link https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Design_Proposal Link to design of new openflowplugin for Lithium
16:47:21 <tbachman> abhijitkumbhare: sorry — wanted to have context
16:47:29 <abhijitkumbhare> np
16:47:50 <tbachman> #info kot-begemot says he read something about changing the way the I/O works — wants to understand what has changed
16:47:56 <colindixon> frustratingly, that isn’t linked from the release plan
16:47:59 <colindixon> :-(
16:48:02 <colindixon> https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Lithium_Release_Plan
16:48:21 <tbachman> #link https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Lithium_Release_Plan OpenFlow plugin Lithium release plan
16:48:24 <tbachman> colindixon: thx!
16:49:12 <abhijitkumbhare> colindixon tbachman - the right link is https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Release_Plan - the redesign is linked from there
16:49:18 <tbachman> #info vishnoianil says that as someone involved for a long time, the pros for the old code are that it’s stable and tested; the pros for the second are the better architecture, but the cons are the performance and stability - but the priority here is cutting the branch
16:49:21 <tbachman> abhijitkumbhare:  thx!
16:49:41 <colindixon> ah
16:49:41 <tbachman> (and thx to colindixon for also providing that link ;) )
16:49:49 <colindixon> it’s not linked as a wiki link
16:49:50 <colindixon> *sigh*
16:49:51 <colindixon> ok
16:50:02 <tbachman> #undo
16:50:02 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x192eb50>
16:50:03 <colindixon> hence this: https://wiki.opendaylight.org/view/Special:WhatLinksHere/OpenDaylight_OpenFlow_Plugin:Lithium_Design_Proposal
16:50:05 <tbachman> #undo
16:50:05 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x1a27710>
16:50:29 <colindixon> so, can we make it so that users can pick which OF plugin implementation they can use
16:50:33 <colindixon> so that some people can use the newer one
16:50:42 <tbachman> #link https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Release_Plan The OpenFlow plugin Lithium release plan, with link to redesign
16:50:53 <rovarga> colindixon: it is already thath way, there are two features
16:50:55 <tbachman> #info colindixon asks if we can make it so that users can pick which OF plugin implementation they can use
16:50:59 <colindixon> ok
16:51:06 <tbachman> #info rovarga says it’s already that way — there are two features
16:51:33 * tbachman was too busy finding links to catch what vishnoianil was saying
16:51:39 <tbachman> #info rovarga asks what’s blocking us from creating the branch
16:51:53 <tbachman> #info vishnoianil thinks the main reason was the IPv6 was the main thing blocking the branch
16:52:00 <tbachman> #info rovarga asks who owns the IPv6 issue
16:52:16 <tbachman> #info kot-begemot says that in the current state, the Lithium gerit will fix everything but the hashing code
16:52:47 <tbachman> #info rovarga asks if we take out the hashing code with those fixes, then we’re good to cut the branch
16:53:02 <abhijitkumbhare> #link https://git.opendaylight.org/gerrit/#/c/20704 Lithium gerritt
16:53:04 <tbachman> #info kot-begemot says taking it out and fixing it is not suitable to be done for freezing
16:53:21 <tbachman> #info kot-begemot says we still have this failing in CI — from a code perspective, the answer is yes
16:57:11 <tbachman> #info jmedved asks how we can solve the problem of cutting the branch
16:57:53 <tbachman> #info rovarga says we can also take this decision to the TSC
16:59:11 <tbachman> #info kot-begemot says the key question is to be whether we should use the Helium or Lithium plugin
16:59:30 <tbachman> #info rovarga says colindixon pointed out that we can ship both and let users decide (currently both features are there)
16:59:45 <tbachman> #info rovarga says what we need to solve is the problem of the stable/lithium branch
16:59:57 <tbachman> #info vishnoianil says he votes for that approach (two features)
17:00:09 <tbachman> #info abhijitkumbhare asks if we’re okay with two implementations or single implementnation
17:00:24 <tbachman> #info abhijitkumbhare says it sounds like most folks are okay with both implementations
17:00:35 <tbachman> #info abhijitkumbhare asks if anyone is opposed to both implementations
17:00:50 <tbachman> #info vishnoianil says he approves, with the default being the Helium plugin
17:01:15 <tbachman> #info abhijitkumbhare says we can make the call as to which is the default at RC0, 1, 2....
17:01:34 <tbachman> #info kot-begemot says he’s fine with that — as long as users have a stable version to work with, he’s fine with that
17:01:57 <tbachman> #agreed: openflowplugin to provide both Helium and Lithium implementations as part of the Lithium release
17:03:19 <tbachman> #startvote Should the committers decide to cut stable/lithium +1,0,-1
17:03:19 <odl_meetbot> Unable to parse vote topic and options.
17:03:23 <tbachman> :(
17:03:38 <tbachman> #startvote Should the committers decide to cut stable/lithium? +1,0,-1
17:03:38 <odl_meetbot> Begin voting on: Should the committers decide to cut stable/lithium? Valid vote options are +1, 0, -1.
17:03:38 <odl_meetbot> Vote using '#vote OPTION'. Only your last vote counts.
17:03:51 <mbobak> #vote +1
17:04:03 <v_demcak> #vote +1
17:04:10 <michal_rehak> #vote +1
17:04:15 <abhijitkumbhare> #vote +1
17:04:20 <tbachman> abhijitkumbhare: can you do a  +1 for anil?
17:04:53 <tbachman> abhijitkumbhare: should I end this vote and start another?
17:05:01 <tbachman> #endvote
17:05:01 <odl_meetbot> Voted on "Should the committers decide to cut stable/lithium?" Results are
17:05:01 <odl_meetbot> +1 (4): mbobak, v_demcak, michal_rehak, abhijitkumbhare
17:05:57 <vishnoianil> #info My vote is +1, we should go ahead with branch cutting given that Ipv?prefix issue is fixed in He code base
17:06:15 <vishnoianil> #we will still stick to both the implementation (He (default) and Li)
17:06:25 <kot-begemot> I will fix it in the Li code base,
17:06:29 <kot-begemot> without the hashing code
17:06:38 <kot-begemot> That needs a full rewrite to be fixable
17:06:48 <vishnoianil> #info we will take on more call on Rc0 about the concerns discussion by the members, on switching to new Li implementaiton
17:06:51 <tbachman> #info we will still stick to both the implementations (Helium default and Lithium)
17:07:04 <kot-begemot> In fact, the current gerrit for Li is a viable fix
17:07:07 <tbachman> #info kot-begemot says he will fix it in the Lithium code base without the hashing code
17:07:25 <vishnoianil> #info if we will not be able to take clear decision on that, we can ship both the implementation in LI release and defer it to User to use either of the feature
17:08:24 <kot-begemot> #info that part is broken as it is now, and needs a rewrite to be a hash. Presently it is not. Adding all values in header fields a hash does not make
17:09:04 <abhijitkumbhare> I think this is all getting jumbled up a bit :)
17:09:30 <abhijitkumbhare> I will try to do an agreed to it
17:09:49 <abhijitkumbhare> #agreed  we should go ahead with branch cutting given that Ipv?prefix issue is fixed in He code base
17:10:03 <abhijitkumbhare> #agreed we will still stick to both the implementation (He (default) and Li)
17:10:22 <abhijitkumbhare> #agreed we will take on more call on Rc0 about the concerns discussion by the members, on switching to new Li implementaiton
17:10:39 <abhijitkumbhare> #agreed if we will not be able to take clear decision on that, we can ship both the implementation in LI release and defer it to User to use either of the feature
17:11:10 <abhijitkumbhare> Should I end meeting with this?
17:11:22 <kot-begemot> I think you covered everything
17:11:28 <abhijitkumbhare> #endmeeting