Sounds good Ryan. There may be something to your idea about the faster releases - and I would like to understand more but I guess that would be more easily discussed in person at the DDF.
On Wed, Feb 24, 2016 at 12:23 PM, Ryan Goulding <[email protected]> wrote: > 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
