Let me clarify: *I do agree that it is a shame we can’t get it into a major release sooner (e.g., through adopting a faster release cadence).*
Regards, Ryan Goulding On Wed, Feb 24, 2016 at 1:19 PM, Ryan Goulding <[email protected]> wrote: > 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
