It seems that there was some miscommunication. During the heated and hurried discussion, one key point was brought up: there are few development resources available in OFP project.
This exact point (albeit with SR1 as the migration target) was brought in the discussion simply because not having the ability to switch the implementation means that the OFP team is locked into supporting the implementation which has shipped in Be for another 8 months, which effectively means that the already scarce resources become spread out between supporting the ‘Beryllium-default’ and ‘Boron-default’ codebases at the same time. That inherently means whatever ‘stable’ support can have slower turnaround to the point where it renders Beryllium deployments unusable and ‘new’ stabilization can be so slow that come August we will find that not enough progress has been made to make the switchover a reality. In the original communication there was no real opposition to this switchover (as far as I remember, and it seems Abhijit’s understanding was the same). Now with the release out, there seems to be opposition – not 8 weeks after the issue was brought originally to the release mailing list. These are two pans of the same balance and as such pros and cons need to weighed carefully. I thought they were, but it seems some feel they weren’t. Thanks, Robert From: [email protected] [mailto:[email protected]] On Behalf Of Ryan Goulding Sent: Wednesday, February 24, 2016 4:39 PM To: Chris Price <[email protected]> Cc: [email protected]; [email protected]; Release <[email protected]> Subject: Re: [release] [openflowplugin-dev] OF-Plugin dependent projects migration plan to Li design in the service releases +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]<mailto:[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]<mailto:[email protected]>> on behalf of Abhijit Kumbhare <[email protected]<mailto:[email protected]>> Date: Tuesday 23 February 2016 at 19:31 To: Release <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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. o 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]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/release _______________________________________________ openflowplugin-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
