Hi Robert,
> OFP team is locked into supporting the implementation which has shipped in > Be for another 8 months >From what I understand, there are ongoing efforts to decrease the amount of time in between major releases. I agree, this is currently a pain point for ODL developers. > 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. I am not convinced that support of the existing plugin is going to detract so heavily as to prevent moving to Lithium design by Boron; after all, the existing plugin has been around since Helium, IIRC. That said, I am not an OFP expert. I do believe that changing plugins in a service release would cost downstream OFP consumers valuable resources for the current development cycle. > 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). I was not involved in that conversation. My apologies, I do not always have time to read every email on this thread. > 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. Have we considered the consequences of swapping plugins in a service release from an end user perspective? This likely involves a full re-qualification for interoperability and performance for all southbound devices. If an end user wishes to pick up stability and security fixes normally contained in a service release, they are also forced to re-qualify that openflow is going to work in their deployment scenario. This may mean deployment adaptations in response to API changes, etc. Requalification effort is not necessarily trivial, and I could certainly envision some users avoiding service upgrades to skate around this effort. Overall, I am not convinced there is a compelling reason to make this change in a service release. I do agree that it is a shame we can’t get it in sooner (e.g., through adopting a faster release cadence). I am open to ideas, thoughts and suggestions as always. Regards, Ryan Goulding On Wed, Feb 24, 2016 at 11:57 AM, Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco) <[email protected]> wrote: > 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]> > 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. > > 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. > > [image: https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif] > > > > 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
