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?
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. --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 >> >> >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
