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
