On Wed, Feb 24, 2016 at 4:11 PM, Colin Dixon <[email protected]> wrote:
> The issue with not not providing the same API (including notifications) in > the Beryllium-SR2 release is that there are projects, users and downstream > consumers that are not projects in OpenDaylight and thus we won't be able > to tell how the will or won't be affected unless we keep full API > compatibility. > > If we lose some APIs in the Beryllium-SR2 release and it causes people to > be unable to upgrade without having to rewrite their applications (as as > Ryan says retest with all devices), then it's not really a stability > release as we've done in the past. > This is very valid point and i think it's probably a big concern from OpenDaylight consumers perspective if users will have to re-write their applications. > I understand your concerns Robert and Abhijit, and agree with Ryan in > empathizing with the motivation to consolidate on a single implementation. > I just worry about breaking the contract we have with people consuming our > releases. > > I look forward to discussing options at the developer design forum. > > --Colin > On Feb 24, 2016 1:37 PM, "Abhijit Kumbhare" <[email protected]> wrote: > >> Addressing the general question (that Colin/Chris/Ryan raised) - I would >> like to make clear this is a plan from the OpenFlow Plugin side but we will >> need to have a joint discussion in a meeting where all the dependent >> projects are present. We are planning this meeting to be at the DDF. >> >> The few important points we have are: >> >> 1. OpenFlow Plugin has few resources to be able to support both the >> designs simultaneously. We will need to balance out the need to support >> both the designs for an extended period of time vs other considerations >> like the one you mentioned. >> 2. With this plan we can focus the resources to the Li design >> significantly more after SR-2. Still we may need support from some folks >> like Anil, etc. to fix some critical issues in the He design on a case by >> case basis - but most others we could say this is fixed in the Lithium >> design as all the OpenDaylight projects would have started consuming the >> Lithium design. >> - If we can achieve this with some other means & yet do not change >> the default used by the projects in Beryllium service releases - I >> would >> like to know. >> - Example: if everyone (especially the consuming projects) >> agrees that the existing/Helium design implementation is really >> stable in >> Beryllium to the point that not many bug fixes will be made in the >> Beryllium service releases & only the real blockers will be fixed. >> Other >> than some known major issues & limitations (the known ones already >> release >> noted) - this is probably true since the design has been around >> since the >> Hydrogen days & we have had very few blockers during the Beryllium >> release >> candidate cycles. >> 3. During the original discussion two months ago - we had >> discussed this plan to do the switchover in the service releases after >> Beryllium - there was not a significant opposition on this. >> >> About the specific questions - answers in-line. >> >> On Wed, Feb 24, 2016 at 6:10 AM, Colin Dixon <[email protected]> >> wrote: >> >>> Two more points as I think about this more: >>> >>> 1.) How are we planning to ship a working Beryllium-SR1 if projects are >>> using the stable/beryllium branch to migrate to the -li plugin from now >>> until Beryllium-SR2? Won't that result in an unstable state when we need to >>> ship Beryllium-SR1? >>> >> >> Abhijit>> As I mentioned in my original email (but probably not clear) - >> we will do the migration in the master and once the migration is successful >> then cherry pick to the stable/beryllium. This cherry pick cannot happen in >> the SR 1 timeframe & will need to be done in the SR2 timeframe. >> >>> >>> 2.) If we do ship this as part of an SR, we need to provide complete API >>> compatibility. This includes the corner cases like port status >>> notifications and the like, which, if I remember correctly, changed between >>> the older and newer implementations. >>> >> >> Abhijit>> The migration exercise will identify which of the notifications >> compatibility corner cases are actually used by the consuming projects & if >> they can use a different method that is more suited to the Lithium design. >> The VTN project had such issues & they have converted their code according >> to the Lithium design. If there is some blocking issue with respect to this >> we will have to either fix it or help the projects with an implementation >> more suited to the Lithium design. >> As far as all the missing notifications (bug 4117) is concerned - we do >> have a set of patches to address this: >> https://git.opendaylight.org/gerrit/#/q/status:open+project:openflowplugin+branch:stable/lithium+topic:BUG-4117 >> . >> But I have not deliberately merged them yet in Beryllium - as it would be >> better for projects to use the Lithium design in the way it was intended to >> be used. We can merge these during SR2 timeframe as a fallback mechanism. >> >> >>> >>> >>> --Colin >>> >>> >>> On Wed, Feb 24, 2016 at 5:57 AM, Colin Dixon <[email protected]> >>> wrote: >>> >>>> My only concern with this plan is that we've told users that the can >>>> expect relative stability from upgrades between SRs and while we may test >>>> projects' functionality internally fairly well to ensure no regressions, my >>>> worry is that there may be a number of external consumers of the OpenFlow >>>> plugin that use it in ways we don't. >>>> >>>> The result is that we may introduce regressions in an SR that could >>>> damage our reputation with users for some time to come. >>>> >>>> I don't think it necessarily prohibits doing this, but it's certainly >>>> something to carefully consider. >>>> >>>> --Colin >>>> >>>> >>>> On Tue, Feb 23, 2016 at 1:31 PM, Abhijit Kumbhare < >>>> [email protected]> wrote: >>>> >>>>> 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. >>>>> - 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. >>>>> >>>>> >>>>> 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 >>>>> >>>>> >>>> >>> >> -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
