Small correction (using the word relatively stable instead of really stable) - please read the corrected one below:
On Wed, Feb 24, 2016 at 10:37 AM, 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 > *relatively* 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
