[Ofa_boardplus] OFED releases

[Woodruff, Robert J]

We have had some discussions with the distro’s (both Redhat and SUSE) to explore the possibility for the OFA and the distro’s to work closer together.
One of the things we discussed was having the distros be able to test early versions of distro releases in the UNHIOL testing lab so that if there
are any interop issues, they could be fixed before the distro version releases. This would require the distros to provide early drops of their code to UNH-IOL
similar to the arrangement they have with certain vendors.  This might allow the in-box distro code to be used for OFA interop logo testing in the future, rather than
using the community OFED, which they do now.
I think where we left it was that the distros were off contemplating it and perhaps also thinking about joining the OFA to facilitate that closer relationship.

Note also that we have been clearly communicating for some time now, that for most production users, they should use the in-box versions of OFA code whenever possible
and only need to install and use the community OFED if they need something that may be in OFED that is not yet in the distro, which is becoming a smaller
and smaller set of things every day.

My 2 cents.

From: Ofa_boardplus [mailto:ofa_boardplus-bounces at lists.openfabrics.org] On Behalf Of Christoph Lameter
Sent: Tuesday, May 16, 2017 2:09 PM
To: Paul Grun <grun at cray.com>
Cc: ofa_boardplus at lists.openfabrics.org
Subject: Re: [Ofa_boardplus] OFED releases

Note that Jason also says that the sites are also actively working on getting stuff submitted upstream to minimize their delta as well as working with the distros to make sure things are straight. We have done that as a company but I do not see OFED do this. If OFED would work in a collaborative way with distros and upstream to ensure that the distros include the necessary changes then that would be a good thing. One of the key things then will have to adopt the methods and processes to work with upstream and the distros and to interact with them in a regular fashion,.

On Tue, May 16, 2017 at 12:48 PM, Paul Grun <grun at cray.com<mailto:grun at cray.com>> wrote:
>The only avenue left is a technical solution - someone has to fund the work to
>actually go and create a fork that matches what the sites need, pulling from the
>vendor forks, and do this faster than the upstream process would get it done.

Would it be unreasonable to think of the EWG as being the technical body that could do what Jason suggests?

>-----Original Message-----
>From: Ofa_boardplus [mailto:ofa_boardplus-bounces at lists.openfabrics.org<mailto:ofa_boardplus-bounces at lists.openfabrics.org>] On
>Behalf Of Jason Gunthorpe
>Sent: Thursday, May 11, 2017 4:05 PM
>To: Atchley, Scott <atchleyes at ornl.gov<mailto:atchleyes at ornl.gov>>
>Cc: ofa_boardplus at lists.openfabrics.org<mailto:ofa_boardplus at lists.openfabrics.org>
>Subject: Re: [Ofa_boardplus] OFED releases
>
>On Thu, May 11, 2017 at 09:44:11PM +0000, Atchley, Scott wrote:
>
>> Again, I am not arguing for a change in anyone’s workflow from pushing
>> upstream first. But while upstream debates implementation and while
>> the eventual design works its way to the distro backports, what should
>> users do with hardware on their floor?
>
>They need to use the fork of the software that vendor provides. There is no other
>answer. Only the vendor is going to be willing to support and develop that forked
>code.
>
>Your #2 problem is the real intractable issue.
>
>The upstream neutral collaborative process is how we have been successful in
>getting the vendors to work together, at all. That has become an industry wide
>defacto agreed upon way to work on a shared code base.
>
>There is no way, politically, to just short circuit that process and keep the vendors
>engaged.
>
>It isn't reasonable to ask the vendors to union their forks of the RDMA stack
>outside of the upstream process - there are overlaps and disagreements, this
>would create a different layer of arguing. As a group, the vendors have no
>incentive to do that.
>
>The only avenue left is a technical solution - someone has to fund the work to
>actually go and create a fork that matches what the sites need, pulling from the
>vendor forks, and do this faster than the upstream process would get it done.
>
>Frankly, this is what all the big cloud operators do internally - they fund a kernel
>and infrastructure development team to mangle the software into the shape they
>want, and upstream things to minimize their maintenance cost.
>
>Jason
>_______________________________________________
>Ofa_boardplus mailing list
>Ofa_boardplus at lists.openfabrics.org<mailto:Ofa_boardplus at lists.openfabrics.org>
>http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus
_______________________________________________
Ofa_boardplus mailing list
Ofa_boardplus at lists.openfabrics.org<mailto:Ofa_boardplus at lists.openfabrics.org>
http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofa_boardplus/attachments/20170516/76cb5825/attachment.html>