OpenFlow Plugin and OpenFlow Java Library


Abhijit Kumbhare
 

Hi folks,

We have 2 projects for OpenFlow - OpenFlow Plugin (connection handling, state management, apps like the FRM, etc.) & OpenFlow Java Library (library for the low level wire protocol implementation). This increases the logistics related to the OpenFlow southbound development (done in two places) and project reporting overhead. The other southbounds like OVSDB, NetConf, etc. do not have two different projects - even if some of them may have a similar split internally (plugin & library).
 
Also more importantly currently most community activity (meetings/discussions for the new features) happen in the OpenFlow Plugin community even though the implementation needs to be done in OF Plugin and OFJ Library. Also going forward OFJ may have only a single active committer (Jozef Bacigal). 

So some of us feel Nitrogen might be a good time to unify these two projects.

The current thought:
  Move all the code from OpenFlow Java Library to the OpenFlow Plugin.

Advantages:
1) This may not need a lot of work. 
2) All active OpenFlow Java committers are also committers on OpenFlow Plugin.
3) Since we are not creating a project & if we do not add any new committers - this may not even need a TSC approval (but we will work with the TSC when we have decided the exact action).

Challenges / open questions:
1) How do we retain history for the OpenFlow Java code for code done before the code movement? The IT experts may have some ideas on this - Thanh, Anil B, Andrew? Also is there a way to subsume a project into another project or merge the repos?
   One obvious solution, we can just keep the OpenFlow Java Library repo still active - even if OpenFlow Java Library does not participate in future simultaneous releases. 
2) How do handle the documentation of the 2 projects? Just move the OpenFlow Java documentation inside the developer guide under OFP documentation?
3) How do we handle the inactive committers of OpenFlow Java Library? If we keep OpenFlow Java Library project active without participating in simultaneous release - we likely do not have to address this problem.

If you have thoughts/suggestions/objections - please reply to this email.

Thanks,
Abhijit


Andrew Grimberg <agrimberg@...>
 

On 06/07/2017 05:21 PM, Abhijit Kumbhare wrote:

Just an FYI IIRC this has happened at least once already. Additionally,
from a different point of view it's similar to the project spin-outs
we've done in the past.

--[snip]--

Challenges / open questions:
1) How do we retain history for the OpenFlow Java code for code done
before the code movement? *The IT experts may have some ideas on this -
Thanh, Anil B, Andrew?* Also is there a way to subsume a project into
another project or merge the repos?
One obvious solution, we can just keep the OpenFlow Java Library repo
still active - even if OpenFlow Java Library does not participate in
future simultaneous releases.
We would not delete the old repo, it would just become a read-only
archived repo.

My suggestion would be to do the following:

* Copy the HEAD of the code base being merged into the target project

* Make the commit message state where it is coming from and the SHA of
the commit it is being taken from (in case the HEAD moves after that for
some reason)

* Request that LF lock the origination repository

2) How do handle the documentation of the 2 projects? Just move the
OpenFlow Java documentation inside the developer guide under OFP
documentation?
I would think this would be the correct method.

3) How do we handle the inactive committers of OpenFlow Java Library? If
we keep OpenFlow Java Library project active without participating in
simultaneous release - we likely do not have to address this problem.
I would think that cleaning up the committer lists before this would be
a paramount issue. Then the committers can formally vote to bring the
old project into archive status so that we have a proper for the
read-only / archive state of the project.

After that upon the code being brought into the other project, elevating
anyone to committer that needs to be would just follow the standard
procedures, though you would be able to point at history in the archived
project as well for making the elevation case.

-Andy-

--
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation


Abhijit Kumbhare
 

Thanks Andy! Lot of good advice there - and a good blueprint to follow.

On Thu, Jun 8, 2017 at 10:50 AM, Andrew Grimberg <agrimberg@...> wrote:
On 06/07/2017 05:21 PM, Abhijit Kumbhare wrote:

Just an FYI IIRC this has happened at least once already. Additionally,
from a different point of view it's similar to the project spin-outs
we've done in the past.

--[snip]--

> Challenges / open questions:
> 1) How do we retain history for the OpenFlow Java code for code done
> before the code movement? *The IT experts may have some ideas on this -
> Thanh, Anil B, Andrew?* Also is there a way to subsume a project into
> another project or merge the repos?
>    One obvious solution, we can just keep the OpenFlow Java Library repo
> still active - even if OpenFlow Java Library does not participate in
> future simultaneous releases.

We would not delete the old repo, it would just become a read-only
archived repo.

My suggestion would be to do the following:

* Copy the HEAD of the code base being merged into the target project

* Make the commit message state where it is coming from and the SHA of
the commit it is being taken from (in case the HEAD moves after that for
some reason)

* Request that LF lock the origination repository

> 2) How do handle the documentation of the 2 projects? Just move the
> OpenFlow Java documentation inside the developer guide under OFP
> documentation?

I would think this would be the correct method.

> 3) How do we handle the inactive committers of OpenFlow Java Library? If
> we keep OpenFlow Java Library project active without participating in
> simultaneous release - we likely do not have to address this problem.

I would think that cleaning up the committer lists before this would be
a paramount issue. Then the committers can formally vote to bring the
old project into archive status so that we have a proper for the
read-only / archive state of the project.

After that upon the code being brought into the other project, elevating
anyone to committer that needs to be would just follow the standard
procedures, though you would be able to point at history in the archived
project as well for making the elevation case.

-Andy-

--
Andrew J Grimberg
Lead, IT Release Engineering
The Linux Foundation



Sam Hague
 

On Wed, Jun 7, 2017 at 8:21 PM, Abhijit Kumbhare <abhijitkoss@gmail.com> wrote:
Hi folks,

We have 2 projects for OpenFlow - OpenFlow Plugin (connection handling,
state management, apps like the FRM, etc.) & OpenFlow Java Library (library
for the low level wire protocol implementation). This increases the
logistics related to the OpenFlow southbound development (done in two
places) and project reporting overhead. The other southbounds like OVSDB,
NetConf, etc. do not have two different projects - even if some of them may
have a similar split internally (plugin & library).

Also more importantly currently most community activity
(meetings/discussions for the new features) happen in the OpenFlow Plugin
community even though the implementation needs to be done in OF Plugin and
OFJ Library. Also going forward OFJ may have only a single active committer
(Jozef Bacigal).

So some of us feel Nitrogen might be a good time to unify these two
projects.

The current thought:
Move all the code from OpenFlow Java Library to the OpenFlow Plugin.

Advantages:
1) This may not need a lot of work.
2) All active OpenFlow Java committers are also committers on OpenFlow
Plugin.
3) Since we are not creating a project & if we do not add any new committers
- this may not even need a TSC approval (but we will work with the TSC when
we have decided the exact action).

Challenges / open questions:
1) How do we retain history for the OpenFlow Java code for code done before
the code movement? The IT experts may have some ideas on this - Thanh, Anil
B, Andrew? Also is there a way to subsume a project into another project or
merge the repos?
We kept history when we split ovsdb/netvirt and then merged netvirt
and vpnservice. The flow Andy used copied all the files into NetVirt
and the history was kept intact. I think I came up with the commands
to use and Andy did the work - but I can't find those emails right
now.

You should also stop the jobs running for the old openflowjava repo
and migrate them to use openflowplugin repo.

One obvious solution, we can just keep the OpenFlow Java Library repo
still active - even if OpenFlow Java Library does not participate in future
simultaneous releases.
2) How do handle the documentation of the 2 projects? Just move the OpenFlow
Java documentation inside the developer guide under OFP documentation?
Yes, this is what we did - just pulled in the relvant docs to netvirt.

3) How do we handle the inactive committers of OpenFlow Java Library? If we
keep OpenFlow Java Library project active without participating in
simultaneous release - we likely do not have to address this problem.

If you have thoughts/suggestions/objections - please reply to this email.

Thanks,
Abhijit


_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev


Abhijit Kumbhare
 

Thanks Sam! We may have some questions as we go further into the process.

On Thu, Jun 8, 2017 at 1:00 PM Sam Hague <shague@...> wrote:
On Wed, Jun 7, 2017 at 8:21 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:
> Hi folks,
>
> We have 2 projects for OpenFlow - OpenFlow Plugin (connection handling,
> state management, apps like the FRM, etc.) & OpenFlow Java Library (library
> for the low level wire protocol implementation). This increases the
> logistics related to the OpenFlow southbound development (done in two
> places) and project reporting overhead. The other southbounds like OVSDB,
> NetConf, etc. do not have two different projects - even if some of them may
> have a similar split internally (plugin & library).
>
> Also more importantly currently most community activity
> (meetings/discussions for the new features) happen in the OpenFlow Plugin
> community even though the implementation needs to be done in OF Plugin and
> OFJ Library. Also going forward OFJ may have only a single active committer
> (Jozef Bacigal).
>
> So some of us feel Nitrogen might be a good time to unify these two
> projects.
>
> The current thought:
>   Move all the code from OpenFlow Java Library to the OpenFlow Plugin.
>
> Advantages:
> 1) This may not need a lot of work.
> 2) All active OpenFlow Java committers are also committers on OpenFlow
> Plugin.
> 3) Since we are not creating a project & if we do not add any new committers
> - this may not even need a TSC approval (but we will work with the TSC when
> we have decided the exact action).
>
> Challenges / open questions:
> 1) How do we retain history for the OpenFlow Java code for code done before
> the code movement? The IT experts may have some ideas on this - Thanh, Anil
> B, Andrew? Also is there a way to subsume a project into another project or
> merge the repos?

We kept history when we split ovsdb/netvirt and then merged netvirt
and vpnservice. The flow Andy used copied all the files into NetVirt
and the history was kept intact. I think I came up with the commands
to use and Andy did the work - but I can't find those emails right
now.

You should also stop the jobs running for the old openflowjava repo
and migrate them to use openflowplugin repo.

>    One obvious solution, we can just keep the OpenFlow Java Library repo
> still active - even if OpenFlow Java Library does not participate in future
> simultaneous releases.
> 2) How do handle the documentation of the 2 projects? Just move the OpenFlow
> Java documentation inside the developer guide under OFP documentation?

Yes, this is what we did - just pulled in the relvant docs to netvirt.

> 3) How do we handle the inactive committers of OpenFlow Java Library? If we
> keep OpenFlow Java Library project active without participating in
> simultaneous release - we likely do not have to address this problem.
>
> If you have thoughts/suggestions/objections - please reply to this email.
>
> Thanks,
> Abhijit
>
>
> _______________________________________________
> openflowjava-dev mailing list
> openflowjava-dev@...
> https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev
>