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. 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 >>>> >>>> >>> >> >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
