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
