Small mistake - should have been - all OF Plugin committers and contributors.
On Thu, Jan 28, 2016 at 9:08 AM, Abhijit Kumbhare <[email protected]> wrote: > Critical bugs should be fixed by all the OF Plugin committers. Some may be > deferred after a bug scrub or release noted as fix being available on the > Lithium design only. Next week I am planning to conduct some bug scrubs > (starting in the OF Plugin meeting if time permits - otherwise exact time > we will determine during the OF Plugin meeting). > > On Tue, Jan 26, 2016 at 3:38 PM, Jan Medved (jmedved) <[email protected]> > wrote: > >> Hi Abhijit, Anil: >> >> So who is going to fix the critical bugs in the He Plugin before the >> release? I think, for example, that the dangling flows / lost flows bugs >> (5073 / 5074) need to be fixed. >> >> I investigated 5073 and 5074 a bit further, and found that for smaller >> networks it occurs a lot sooner than with 100k flows. With a 7-node >> network, I could reproduce with 40k flows; with a 3-node network I could >> reproduce with 20k flows. Basically, when the number of flows gets to >> around 4k per switch, there is a problem. >> >> >> Thanks, >> Jan >> >> >> From: <[email protected]> on behalf of Abhijit Kumbhare >> <[email protected]> >> Date: Monday, January 25, 2016 at 10:16 PM >> To: Anil Vishnoi <[email protected]> >> Cc: "[email protected]" <[email protected]> >> Subject: Re: [OpenDaylight TSC] OpenFlow Plugin Designs Conflict >> >> Thanks Luis for summarizing the meeting info. Fully agree with the >> approach of going for the change in one of the SRs which would provide the >> projects some time to consume - and we will also get time to flesh out if >> any new major issues come out. >> >> We have now had meetings on this last week - as well as a very productive >> meeting yesterday. Unless there is some new angle - we can go with the >> roughly agreed tactics: >> >> >> - "Be" has the option for consumers building apps/products on top of >> ODL OpenFlow Plugin to use the "Li design" >> - As decided, "Be" at release still has the default design consumed >> by OFP apps as the existing "He" design with the following caveats: >> - The release notes issues mark some of them as already fixed in >> the "Li" design. That way users who need the enhancements/fixes can >> immediately go for the "Li" design. >> - (The following point not completely agreed by all the parties): OFP >> consumers work on the change to support the Li design in the service >> release cycle (SR1 - if SR1 not possible then SR2). The blocker issues >> identified by the projects (perhaps related to API compatibility) as well >> as the current issues in the "Li" design like bug 4925 & 5001 need to be >> fixed by then to make the switch. >> >> I will be traveling back to San Jose - so may not get time to respond >> till Wednesday. >> >> On Tue, Jan 26, 2016 at 7:08 AM, Anil Vishnoi <[email protected]> >> wrote: >> >>> >>> >>> On Mon, Jan 25, 2016 at 4:17 PM, Jamo Luhrsen <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On 01/25/2016 03:36 PM, Anil Vishnoi wrote: >>>> > So if we won't be able to finish the migration by SR1, what should be >>>> we do ? Document the outstanding issue and release >>>> > (not sure whether we will be able to release it as well, in case few >>>> project won't be able to migrated) OR slip it for >>>> > some more time lets see till SR2 release date with the hope that >>>> projects will be able to move by that time ? >>>> >>>> I guess my (internal) assumption was that we wouldn't go down the route >>>> of delaying >>>> the initial Beryllium release unless it was considered something we >>>> could really >>>> pull off in that delay period. So, if we got to SR1 and weren't quite >>>> there, hopefully >>>> we aren't far off. >>>> >>>> > >>>> > First option can put us again in the same spot where we are now. In >>>> my opinion, doing it on SR will give us flexibility >>>> > in that term, that we can switch to Li as a default plugin at SR1 if >>>> all project migrates by that time or we can slip it >>>> > to SR2 to give some more time to projects. And about caveats and >>>> confusion, i am not sure we can guarantee that it won't >>>> > happen once we move to Li plugin as well, given the API >>>> incompatibilities we have. >>>> >>>> If we are moving to just Li plugin, then there are no incompatibilities >>>> right? it's just >>>> one plugin only, one API set, one feature set, etc. We might have some >>>> explaining to >>>> do so that what's now different is easy to understand and consume. >>>> >>>> > >>>> > IMHO, looking at number of projects using the openflowplugin, we need >>>> to weigh in projects feedback as well, because i >>>> > am not sure enforcing all the projects (>20) to migrate to new >>>> plugin now will help us what we want to achieve. >>>> >>>> I guess I'm not lobbying for a delay or wishing extra/difficuly work on >>>> any projects. But, >>>> if we do think it's possible for every project to move (with testing, >>>> fixing, etc) in a >>>> *bearable* time frame, then it seems cleaner to take our medicine now. >>>> >>> I know you, so thought of lobbying never comes to my mind :-). I just >>> expressed my opinion, i personally prefers to plan against worst case and >>> not the best case. :) >>> So finding that bearable time is something that depends on individual >>> dependent projects, so i would prefer them to speak up and express their >>> opinion. >>> >>>> >>>> JamO >>>> >>>> >>>> > On Mon, Jan 25, 2016 at 3:20 PM, Luis Gomez <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> > >>>> > Hi Jamo, >>>> > >>>> > Good question, I guess that is a possibility but given the amount >>>> of delay we are talking here, we should probably >>>> > need a good discussion/consensus on that. >>>> > >>>> > BR/Luis >>>> > >>>> > >>>> > >>>> > > On Jan 25, 2016, at 12:48 PM, Jamo Luhrsen <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> > > >>>> > > >>>> > > >>>> > > On 01/25/2016 12:24 PM, Anil Vishnoi wrote: >>>> > >> >>>> > >> >>>> > >> On Mon, Jan 25, 2016 at 10:47 AM, Luis Gomez <[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> > <mailto:[email protected]>>> wrote: >>>> > >> >>>> > >> So as we discussed in OFP call today, Li design addresses >>>> some of the He design issues and limitations: >>>> > >> >>>> > >> - Stats collection delay >>>> > >> - Flow/Group push ordering >>>> > >> - Bulk flow add/remove operations >>>> > >> >>>> > >> But we need some time for: >>>> > >> >>>> > >> - ODL projects to migrate to new plugin >>>> > >> - OFP devs to fix some issues in Li plugin >>>> > >> >>>> > >> For these reasons I think moving to new plugin by Beryllium >>>> release is risky but moving by SR1 is a good idea >>>> > if we >>>> > >> can do it. >>>> > >> >>>> > >> +1, I think that will give some time to fix issues in >>>> existing lithium plugin and also projects will have time >>>> > to put >>>> > >> this migration on their priority. >>>> > > >>>> > > I'm guessing it's obvious to others, but not to me. What's >>>> wrong with not having >>>> > > the Beryllium release until SR1, and delaying everything by >>>> that one cycle? >>>> > > >>>> > > Otherwise, Beryllium is released with all the caveats and >>>> confusion; extra >>>> > > documentation and incompatibilities, etc. Then SR1 comes out >>>> with none of >>>> > > that. >>>> > > >>>> > > JamO >>>> > > >>>> > >> BR/Luis >>>> > >> >>>> > >> >>>> > >>> On Jan 25, 2016, at 9:43 AM, Robert Varga <[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> > <mailto:[email protected]>>> wrote: >>>> > >>> >>>> > >>> On 01/25/2016 05:11 PM, Colin Dixon wrote: >>>> > >>>> So, I there are a few questions I'd ask about option 3: >>>> > >>>> >>>> > >>>> (a) since this amounts of option 2 at the time of release, >>>> have gathered information about the relevant features >>>> > >> to make sure we understand which features depend on each >>>> design of the the plugin and that nobody would want to >>>> > >> simultaneously install any that conflict? >>>> > >>> >>>> > >>> I think this could be done in a TWS call, or inter-project >>>> syncup. >>>> > >>> >>>> > >>>> >>>> > >>>> (b) again since this amounts to option 2 at the time of >>>> release, we need to at least very carefully document >>>> > >> incompatible features, we already have to do some of that. >>>> Thus, I'm assuming we'd be OK with this, but we should >>>> > >> still think about it? >>>> > >>>> >>>> > >>>> (c) do we really want to set in stone that we're moving to >>>> the new design and that we are going to do it in SR1? >>>> > >> At the very least, I think we need to commit to fixing any >>>> regressions as reported by downstream projects, e.g., >>>> > >> VTN's performance issues and Muthu's reported clustering >>>> stability, before switching. >>>> > >>> >>>> > >>> I would assume this as a matter of course. >>>> > >>> >>>> > >>>> While the decision about which of the OpenFlow plugin >>>> designs to go forward with falls to that project's >>>> > >> committers barring any cross-project disputes, I have to >>>> admit that it's hard for me to take it lightly given the >>>> > >> concerns Anil raised about familiarity with the code in the >>>> new design outside of a small team at Pantheon >>>> > >> especially when that is combined with that same team at >>>> least once in the past stating that they intended to >>>> > >> withdraw from working on the project. >>>> > >>> >>>> > >>> I can see Anil's concern given that he wrote some of the old >>>> design. I am not sure whether these have been raised >>>> > >> before, but I think the entire effort was done in a very >>>> open manner, communicated very clearly in terms of >>>> > >> architecture, goals as well as motivation. The code has >>>> been sitting in the repository for better part of the >>>> > past 6 >>>> > >> months. >>>> > >>> >>>> > >>> I guess there is not current best practice of how to >>>> alleviate these issues, especially on the question of who >>>> > >> initiates/drives TOIs and similar. This is probably going >>>> to be the case >>>> > >>> >>>> > >>>> For those reasons, it would seem to make more sense to me to >>>> work these issues out while we can have a longer, >>>> > >> less stressed discussion during the Boron release cycle. If >>>> people feel like we can do that, by SR1, I'm open >>>> > to it, >>>> > >> but put me in the skeptical camp. >>>> > >>> >>>> > >>> I think that is fair. I also think we need some input from >>>> the wider community and have some estimates as to what >>>> > >> is the scope of migration. Some projects have not responded >>>> to the original query, which worries me quite a bit. >>>> > >>> >>>> > >>> Finally, I think we should have some input from people >>>> fielding and using these, as to what is their preference >>>> > >> and why. >>>> > >>> >>>> > >>> Thanks, >>>> > >>> Robert >>>> > >>> >>>> > >>> _______________________________________________ >>>> > >>> TSC mailing list >>>> > >>> [email protected] <mailto:[email protected]> >>>> <mailto:[email protected] >>>> > <mailto:[email protected]>> >>>> > >>> https://lists.opendaylight.org/mailman/listinfo/tsc >>>> > >> >>>> > >> _______________________________________________ >>>> > >> TSC mailing list >>>> > >> [email protected] <mailto: >>>> [email protected]> <mailto:[email protected] >>>> > <mailto:[email protected]>> >>>> > >> https://lists.opendaylight.org/mailman/listinfo/tsc >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> -- >>>> > >> Thanks >>>> > >> Anil >>>> > >> >>>> > >> >>>> > >> _______________________________________________ >>>> > >> TSC mailing list >>>> > >> [email protected] <mailto:[email protected]> >>>> > >> https://lists.opendaylight.org/mailman/listinfo/tsc >>>> > >> >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Thanks >>>> > Anil >>>> >>> >>> >>> >>> -- >>> Thanks >>> Anil >>> >>> _______________________________________________ >>> TSC mailing list >>> [email protected] >>> https://lists.opendaylight.org/mailman/listinfo/tsc >>> >>> >> >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
