+1, great point Chris. The ability to cherry pick back critical patches that affect security or product stability is necessary to drive user success. Unfortunately, I fail to see how swapping OFP implementations fits into either of those categories. Seems like a very large API and functionality change for a "stable" service release.
Regards, Ryan Goulding On Wed, Feb 24, 2016 at 6:52 AM, Chris Price <[email protected]> wrote: > Hi Abhijit, > > I realise I am not an OpenFlow committer any more, but having read this > can I ask. > > Are we asking projects to move from one implementation of the plugin to > another as part of a Stable release? > Have all project signed off that they can and will move? It seems curious > (read dubious) to force projects to change implementation as part of an SR > activity… I had previously understood this migration would occur in Boron > as a planned release activity. > > / Chris > > From: <[email protected]> on behalf of Abhijit > Kumbhare <[email protected]> > Date: Tuesday 23 February 2016 at 19:31 > To: Release <[email protected]> > Cc: "[email protected]" <[email protected]>, " > [email protected]" < > [email protected]> > Subject: [release] OF-Plugin dependent projects migration plan to Li > design in the service releases > > 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 > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
