Ryan, Please read my latest email and let me know your thoughts. Especially the second point - as that is the question we need to solve. We can discuss this more in the DDF if you prefer - if you are going to be present there that's great - but I believe Phil will be trying to schedule this at 10 am Pacific & it will be possible to participate remotely.
Abhijit On Wed, Feb 24, 2016 at 10:29 AM, Ryan Goulding <[email protected]> wrote: > 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 > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
