[OpenDaylight TSC] How to handle vendor specific code

Edward Warnicke hagbard at gmail.com
Fri Feb 20 18:29:40 UTC 2015


Sarwar,

I think you make a good point here.  In addition... its actually really
important that things *work* out of tree (we did a lot to make that doable
for OF extensions)... and the best way to guarantee that you *can* do out
of tree and it keeps working is to do so...

Ed

P.S.  I'm just drive by commenting here... so don't read deep thought or
strong opinion into my comments ;)

On Fri, Feb 20, 2015 at 7:57 AM, Raza, Sarwar S. (NFV Business Unit) <
sarwar.s.raza at hp.com> wrote:

>  Consider please the lesson from Neutron, where third party drivers and
> plugins co-resided in the trunk with the Neutron framework code. Those
> repos are now separate for a host of very good reasons, the most important
> of which (to me) is that it is impossible to get test coverage for third
> party code in a shared testing infrastructure UNLESS every vendor commits
> to standing up or donating the appropriate devices. Neutron now splits out
> the third party plugins.
>
>
>
> \Sarwar
>
>
>
> *Sarwar Raza*
>
> Senior Director, Product Management
>
> Network Functions Virtualization (NFV)
>
> Hewlett-Packard
>
> +1 (978)-760-3701 (mobile)
>
> sarwar.raza at hp.com
>
>
>
> *From:* tsc-bounces at lists.opendaylight.org [mailto:
> tsc-bounces at lists.opendaylight.org] *On Behalf Of *Colin Dixon
> *Sent:* Friday, February 20, 2015 9:41 AM
> *To:* Dean, Steve
> *Cc:* tsc at lists.opendaylight.org
> *Subject:* Re: [OpenDaylight TSC] How to handle vendor specific code
>
>
>
> This is a good question and I'm not sure exactly on the answer. The only
> place where vendor neutrality is mentioned that I can find is in the
> project lifecycle during the creation review. See section 2.3.1 here:
> http://www.opendaylight.org/project-lifecycle-releases
>
> That being said, we have code for the "Nicira extensions" to OpenFlow.
> There was likely a point in time where they were not vendor neutral, but I
> think many people would ague that they (and OVS) are now vendor neutral.
>
> As a practical matter I think it would be good (for code modularity) to
> show that the vendor/device-specific code *could* be written without having
> tog change or recompile the code in ODL, but it would also be good for
> users of ODL to not have to download additional stuff just to get it to
> work with their devices.
>
> What do others think?
>
>
>
> --Colin
>
>
>
> On Thu, Feb 19, 2015 at 6:48 PM, Dean, Steve <sdean at hp.com> wrote:
>
>  Hello,
>
>
>
> I’d like to get TSC members opinion and guidance for how to handle vendor
> specific code.  The DIDM project is developing the framework to support
> device specific functionality.  We are also developing Drivers that
> implement device specific functionality.  Can vendor specific Drivers be
> stored in the ODL source repository, or should they be separate and outside
> of ODL.
>
>
>
> Thanks
>
> Steve
>
>
> _______________________________________________
> TSC mailing list
> TSC at lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/tsc
>
>
>
> _______________________________________________
> TSC mailing list
> TSC at lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/tsc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/tsc/attachments/20150220/7e4c88bd/attachment.html>


More information about the TSC mailing list