Hi Abhijit, I'll be there, and I'll try my best to make it to the session.
Best Regards, Ryan Goulding On Wed, Feb 24, 2016 at 1:53 PM, Abhijit Kumbhare <[email protected]> wrote: > 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
