Date
1 - 9 of 9
Projects: OCP Plugin & OCP Protocol Library
|
Richard Chien <m8809301@...>
Hi,
I'm writing this email to let you know that we have submitted two project proposals for review. Here are the links to the project proposal page. Thank you. https://wiki.opendaylight.org/view/Project_Proposals:OCP_Plugin https://wiki.opendaylight.org/view/Project_Proposals:OCP_Protocol_Library Richard Chien |
|
|
|
Colin Dixon
Out of curiosity, is there a reason you'd like to have two projects rather than one? --ColinOn Wed, Dec 30, 2015 at 1:39 AM, Richard Chien <m8809301@...> wrote:
|
|
|
|
Robert Varga
It does seem it is inspired by what we have in OpenFlow world. The
reasons for the split in OF are mostly due to the requirement to
support multiple incompatible version (1.0 and 1.3 in OFJ),
providing a single northbound interface and performing translation
(OFP).
toggle quoted message
Show quoted text
Looking at the scope of the plugin, I am not sure whether 'device management' is on a per-device basis, or it is something network-wide. From implementation experience I strongly suggest to package the implementation so that everything required to manage a single device (and project its capabilities cleanly via MDSAL) is kept within a single project (as is done for BGP and PCEP), as then you do not have inter-project API friction, which has been a major source of headache between OFJ/OFP. If there is a network-wide component sitting on top of the devices, that should be a separate project (like we are splitting netvirt from OVSDB). Bye, Robert On 2016-01-06 15:29, Colin Dixon wrote:
|
|
|
|
Colin Dixon
+1 to what Robert said. In general, interfaces that are likely to be tightly-coupled, e.g., between a protocol implementation and it's serialization library, are generally better kept within a project where updates can be made consistently. On Wed, Jan 6, 2016 at 3:31 PM, Robert Varga <nite@...> wrote:
|
|
|
|
Richard Chien <m8809301@...>
I totally agree with you/Robert. Indeed, as far as OCP is concerned, it would make more sense to have one project rather than two. We will package the ocpplugin and ocpjava implementation into one project. Thanks to OFJ/OFP, they do provide a good starting point for our implementation and speed the development. BTW, the device management in OCP is on a per-device basis, which provides elementary functions such as health check, device reset and set time. -Richard Date: Wed, 6 Jan 2016 15:42:00 -0500 Subject: Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library
From: colin@... To: nite@... CC: m8809301@...; project-proposals@... +1 to what Robert said. In general, interfaces that are likely to be tightly-coupled, e.g., between a protocol implementation and it's serialization library, are generally better kept within a project where updates can be made consistently. On Wed, Jan 6, 2016 at 3:31 PM, Robert Varga <nite@...> wrote:
|
|
|
|
Colin Dixon
As a follow-up, I'm assuming you want to join the Boron release and I'm assuming you want to do so as an offset 1 project, is that right? --Colinhttps://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan#Project_Offsets On Wed, Jan 6, 2016 at 8:28 PM, Richard Chien <m8809301@...> wrote:
|
|
|
|
Richard Chien <m8809301@...>
Right. It's great to be a part of the ODL distribution. -Richard Date: Thu, 10 Mar 2016 14:06:13 -0500 Subject: Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library
From: colin@... To: m8809301@... CC: nite@...; project-proposals@... As a follow-up, I'm assuming you want to join the Boron release and I'm assuming you want to do so as an offset 1 project, is that right? --Colinhttps://wiki.opendaylight.org/view/Simultaneous_Release:Boron_Release_Plan#Project_Offsets On Wed, Jan 6, 2016 at 8:28 PM, Richard Chien <m8809301@...> wrote:
|
|
|
|
Colin Dixon
I that case, I encourage you to note that the M1 milestone readout is due Thursday by 11:59p UTC.
toggle quoted message
Show quoted text
An will send out a mail like this for offset 1 projects: The template will be the same though, so you could just use that. Also, it probably makes sense to familiarize yourself with the Boron release plan: On Friday, March 11, 2016, Richard Chien <m8809301@...> wrote:
|
|
|
|
Richard Chien <m8809301@...>
Okay, I will start working on the project release plan. Thanks.
toggle quoted message
Show quoted text
-Richard Sent from my ASUS -------- 原始郵件 -------- 寄件者：Colin Dixon 傳送日期：Mon, 14 Mar 2016 20:23:26 +0800 收件者：Richard Chien 副本：project-proposals@... 主旨:Re: [Project-proposals] Projects: OCP Plugin & OCP Protocol Library I that case, I encourage you to note that the M1 milestone readout is due Thursday by 11:59p UTC.
An will send out a mail like this for offset 1 projects:
The template will be the same though, so you could just use that.
Also, it probably makes sense to familiarize yourself with the Boron release plan:
|
|
|