The concerned stakeholders in OpenFlow Plugin project at the DDF (Robert, Anil, Kamal, Shuva, An & I) met yesterday - and we decided to keep the migration to the Lithium design in the Boron release & not in the Beryllium SRs. However - we need to have projects to migrate to the Lithium design as soon as possible. As we develop the Boron schedule - we will need to come up with the milestone by which projects should have migrated. We (OpenFlow plugin + dependent projects) will need to work together to make that milestone happen.
On Thu, Feb 25, 2016 at 10:53 AM, Anil Vishnoi <[email protected]> wrote: > > > On Wed, Feb 24, 2016 at 4:11 PM, Colin Dixon <[email protected]> wrote: > >> The issue with not not providing the same API (including notifications) >> in the Beryllium-SR2 release is that there are projects, users and >> downstream consumers that are not projects in OpenDaylight and thus we >> won't be able to tell how the will or won't be affected unless we keep full >> API compatibility. >> >> If we lose some APIs in the Beryllium-SR2 release and it causes people to >> be unable to upgrade without having to rewrite their applications (as as >> Ryan says retest with all devices), then it's not really a stability >> release as we've done in the past. >> > This is very valid point and i think it's probably a big concern from > OpenDaylight consumers perspective if users will have to re-write their > applications. > > >> I understand your concerns Robert and Abhijit, and agree with Ryan in >> empathizing with the motivation to consolidate on a single implementation. >> I just worry about breaking the contract we have with people consuming our >> releases. >> >> I look forward to discussing options at the developer design forum. >> >> --Colin >> On Feb 24, 2016 1:37 PM, "Abhijit Kumbhare" <[email protected]> >> wrote: >> >>> Addressing the general question (that Colin/Chris/Ryan raised) - I would >>> like to make clear this is a plan from the OpenFlow Plugin side but we will >>> need to have a joint discussion in a meeting where all the dependent >>> projects are present. We are planning this meeting to be at the DDF. >>> >>> The few important points we have are: >>> >>> 1. OpenFlow Plugin has few resources to be able to support both the >>> designs simultaneously. We will need to balance out the need to support >>> both the designs for an extended period of time vs other considerations >>> like the one you mentioned. >>> 2. With this plan we can focus the resources to the Li design >>> significantly more after SR-2. Still we may need support from some folks >>> like Anil, etc. to fix some critical issues in the He design on a case by >>> case basis - but most others we could say this is fixed in the Lithium >>> design as all the OpenDaylight projects would have started consuming the >>> Lithium design. >>> - If we can achieve this with some other means & yet do not >>> change the default used by the projects in Beryllium service releases >>> - I >>> would like to know. >>> - Example: if everyone (especially the consuming projects) >>> agrees that the existing/Helium design implementation is really >>> stable in >>> Beryllium to the point that not many bug fixes will be made in the >>> Beryllium service releases & only the real blockers will be fixed. >>> Other >>> than some known major issues & limitations (the known ones already >>> release >>> noted) - this is probably true since the design has been around >>> since the >>> Hydrogen days & we have had very few blockers during the Beryllium >>> release >>> candidate cycles. >>> 3. During the original discussion two months ago - we had >>> discussed this plan to do the switchover in the service releases after >>> Beryllium - there was not a significant opposition on this. >>> >>> About the specific questions - answers in-line. >>> >>> On Wed, Feb 24, 2016 at 6:10 AM, Colin Dixon <[email protected]> >>> wrote: >>> >>>> Two more points as I think about this more: >>>> >>>> 1.) How are we planning to ship a working Beryllium-SR1 if projects are >>>> using the stable/beryllium branch to migrate to the -li plugin from now >>>> until Beryllium-SR2? Won't that result in an unstable state when we need to >>>> ship Beryllium-SR1? >>>> >>> >>> Abhijit>> As I mentioned in my original email (but probably not clear) - >>> we will do the migration in the master and once the migration is successful >>> then cherry pick to the stable/beryllium. This cherry pick cannot happen in >>> the SR 1 timeframe & will need to be done in the SR2 timeframe. >>> >>>> >>>> 2.) If we do ship this as part of an SR, we need to provide complete >>>> API compatibility. This includes the corner cases like port status >>>> notifications and the like, which, if I remember correctly, changed between >>>> the older and newer implementations. >>>> >>> >>> Abhijit>> The migration exercise will identify which of the >>> notifications compatibility corner cases are actually used by the consuming >>> projects & if they can use a different method that is more suited to the >>> Lithium design. The VTN project had such issues & they have converted their >>> code according to the Lithium design. If there is some blocking issue with >>> respect to this we will have to either fix it or help the projects with an >>> implementation more suited to the Lithium design. >>> As far as all the missing notifications (bug 4117) is concerned - we do >>> have a set of patches to address this: >>> https://git.opendaylight.org/gerrit/#/q/status:open+project:openflowplugin+branch:stable/lithium+topic:BUG-4117 >>> . >>> But I have not deliberately merged them yet in Beryllium - as it would >>> be better for projects to use the Lithium design in the way it was intended >>> to be used. We can merge these during SR2 timeframe as a fallback >>> mechanism. >>> >>> >>>> >>>> >>>> --Colin >>>> >>>> >>>> On Wed, Feb 24, 2016 at 5:57 AM, Colin Dixon <[email protected]> >>>> wrote: >>>> >>>>> My only concern with this plan is that we've told users that the can >>>>> expect relative stability from upgrades between SRs and while we may test >>>>> projects' functionality internally fairly well to ensure no regressions, >>>>> my >>>>> worry is that there may be a number of external consumers of the OpenFlow >>>>> plugin that use it in ways we don't. >>>>> >>>>> The result is that we may introduce regressions in an SR that could >>>>> damage our reputation with users for some time to come. >>>>> >>>>> I don't think it necessarily prohibits doing this, but it's certainly >>>>> something to carefully consider. >>>>> >>>>> --Colin >>>>> >>>>> >>>>> On Tue, Feb 23, 2016 at 1:31 PM, Abhijit Kumbhare < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi folks, >>>>>> >>>>>> In the OpenFlow Plugin meeting yesterday we talked about the >>>>>> migration to the Lithium design for all the projects consuming OpenFlow >>>>>> Plugin and we decided the following migration path makes the most sense: >>>>>> >>>>>> >>>>>> 1. The SR1 is due March 17 (cutoff March 13) & we have some >>>>>> issues (mentioned later in the email) we should fix before migration. >>>>>> Hence >>>>>> these should be fixed in SR1. These issues will be marked as blockers >>>>>> for >>>>>> easier tracking. >>>>>> 2. *ACTION for dependent projects: *The dependent projects should >>>>>> start work on migration *immediately (now)* and finish by SR2 >>>>>> (April 28 - cutoff April 24). This will also give OF Plugin a chance >>>>>> to fix >>>>>> new issues identified by the dependent projects. >>>>>> 3. The plugin migration will first be started in the master and >>>>>> then cherry picked to Beryllium. >>>>>> >>>>>> Other important planning points to note >>>>>> >>>>>> 1. To help find issues faster (for projects & for OpenFlow >>>>>> plugin) - Anil will have an unmerged patch for master (& perhaps >>>>>> stable/beryllium) which will flip the default plugin design to the >>>>>> Lithium >>>>>> design. >>>>>> Using the patch the projects can locally build openflowplugin >>>>>> master branch, that way we don't have to merge it in master. We will >>>>>> not >>>>>> merge the patch right away - as merging the patch can block the >>>>>> projects' >>>>>> ongoing development work, if things started breaking from >>>>>> openflowplugin >>>>>> side. >>>>>> - When fixing issues for the Lithium design with this unmerged >>>>>> patch - care must be taken not to break the Helium design >>>>>> otherwise the >>>>>> master branch may be broken. >>>>>> 2. Luis will create a distribution based on Anil's patch and >>>>>> then we can run the integration tests on it. >>>>>> >>>>>> 3. According to Hideyuki - VTN has already unmerged patch ( >>>>>> https://git.opendaylight.org/gerrit/#/c/35118/) for the >>>>>> migration. However they have run into a performance issue when using >>>>>> the >>>>>> RPCs. >>>>>> 4. The VTN patch will be useful for Luis' distribution with the >>>>>> default as Lithium. >>>>>> >>>>>> >>>>>> Issues that need to be fixed: >>>>>> >>>>>> 1) OF1.0 issue: >>>>>> >>>>>> >>>>>> https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-1node-flow-services-lithium-redesign-only-beryllium/ >>>>>> https://bugs.opendaylight.org/show_bug.cgi?id=5328 >>>>>> >>>>>> 2) Cluster issues: >>>>>> >>>>>> >>>>>> https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-3node-clustering-only-beryllium/ >>>>>> https://bugs.opendaylight.org/show_bug.cgi?id=5388 >>>>>> >>>>>> >>>>>> 3) Stability issues: >>>>>> >>>>>> >>>>>> https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-1node-periodic-longevity-lithium-redesign-only-beryllium/ >>>>>> https://bugs.opendaylight.org/show_bug.cgi?id=5271 >>>>>> https://bugs.opendaylight.org/show_bug.cgi?id=4925 >>>>>> >>>>>> We will have a session in the DDF ( >>>>>> https://wiki.opendaylight.org/view/Events:Boron_Dev_Forum#OpenFlow_Plugin_.26_OpenFlow_Plugin_Dependent_Projects_Planning) >>>>>> regarding this where we can discuss more (in addition to any email). >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Abhijit >>>>>> >>>>>> _______________________________________________ >>>>>> release mailing list >>>>>> [email protected] >>>>>> https://lists.opendaylight.org/mailman/listinfo/release >>>>>> >>>>>> >>>>> >>>> >>> > > > -- > Thanks > Anil >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
