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. 2. 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. 3. Luis will create a distribution based on Anil's patch and then we can run the integration tests on it. 4. 5. 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. 6. 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/openflowplug in-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/openflowplug in-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/openflowplug in-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
