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
