rdma-core release?

rdma-core release?

[Christoph Hellwig]

Are we planning on having a rdma-core release now that 4.8 is out
and we want a matching userspace release?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core release?

[Leon Romanovsky]

On Wed, Oct 12, 2016 at 1:51 PM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> Are we planning on having a rdma-core release now that 4.8 is out
> and we want a matching userspace release?

As far as I remember, the initial plan was to use this library
immediately, but first release was planned to be at the 4.9
announcement to ensure that it runs smoothly.


> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core release?

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 566 bytes --]

On 10/12/2016 7:43 AM, Leon Romanovsky wrote:
> On Wed, Oct 12, 2016 at 1:51 PM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>> Are we planning on having a rdma-core release now that 4.8 is out
>> and we want a matching userspace release?
> 
> As far as I remember, the initial plan was to use this library
> immediately, but first release was planned to be at the 4.9
> announcement to ensure that it runs smoothly.

Correct.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

RE: rdma-core release?

[Steve Wise]

> 
> On 10/12/2016 7:43 AM, Leon Romanovsky wrote:
> > On Wed, Oct 12, 2016 at 1:51 PM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> >> Are we planning on having a rdma-core release now that 4.8 is out
> >> and we want a matching userspace release?
> >
> > As far as I remember, the initial plan was to use this library
> > immediately, but first release was planned to be at the 4.9
> > announcement to ensure that it runs smoothly.
> 
> Correct.
> 

I recommend we release something for OFED-4.8 to pull in.  That might help flush out the release process earlier rather than later.   Either way, though, I want the latest libcxgb4 in OFED-4.8 to support the new chelsio HW.   But we talked about the repo being "always stable", so I guess the OFA could just pull the code and use it?  Still would be nice to have it released...

Steve.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core release?

['Christoph Hellwig']

On Wed, Oct 12, 2016 at 09:43:08AM -0500, Steve Wise wrote:
> I recommend we release something for OFED-4.8 to pull in.  That might help flush out the release process earlier rather than later.   Either way, though, I want the latest libcxgb4 in OFED-4.8 to support the new chelsio HW.   But we talked about the repo being "always stable", so I guess the OFA could just pull the code and use it?  Still would be nice to have it released...

Yeah, I'd much prefer to release early, release often.  If people
don't feel quite comfortable with the new bundle yet we can officially
call it a pre-release.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core release?

[Jason Gunthorpe]

On Wed, Oct 12, 2016 at 09:31:49AM -0700, 'Christoph Hellwig' wrote:
> On Wed, Oct 12, 2016 at 09:43:08AM -0500, Steve Wise wrote:
> > I recommend we release something for OFED-4.8 to pull in.  That
> > might help flush out the release process earlier rather than
> > later.  Either way, though, I want the latest libcxgb4 in OFED-4.8
> > to support the new chelsio HW.  But we talked about the repo being
> > "always stable", so I guess the OFA could just pull the code and
> > use it?  Still would be nice to have it released...
> 
> Yeah, I'd much prefer to release early, release often.  If people
> don't feel quite comfortable with the new bundle yet we can officially
> call it a pre-release.

One of the best ways to get it tested is to get it to go through the
full OFED process.

Woody, what could we do to help make that happen? Do you know of any
blocker?

I think this will be the best for everyone. I also predict that OFED
will be under pressure to quickly take up the new drivers that will
land in 4.9, and their user space will live in rdma-core.

I also propose we give someone from the OFED team repo access and they
can maintain a public branch for ofed-4.8 with any backported fixes.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core release?

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

On Wed, Oct 12, 2016 at 10:47:59AM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 12, 2016 at 09:31:49AM -0700, 'Christoph Hellwig' wrote:
> > On Wed, Oct 12, 2016 at 09:43:08AM -0500, Steve Wise wrote:
> > > I recommend we release something for OFED-4.8 to pull in.  That
> > > might help flush out the release process earlier rather than
> > > later.  Either way, though, I want the latest libcxgb4 in OFED-4.8
> > > to support the new chelsio HW.  But we talked about the repo being
> > > "always stable", so I guess the OFA could just pull the code and
> > > use it?  Still would be nice to have it released...
> >
> > Yeah, I'd much prefer to release early, release often.  If people
> > don't feel quite comfortable with the new bundle yet we can officially
> > call it a pre-release.
>
> One of the best ways to get it tested is to get it to go through the
> full OFED process.

No problem, I'll grab all remaining patches from ML tomorrow and we will
be ready for first release.

>
> Woody, what could we do to help make that happen? Do you know of any
> blocker?
>
> I think this will be the best for everyone. I also predict that OFED
> will be under pressure to quickly take up the new drivers that will
> land in 4.9, and their user space will live in rdma-core.
>
> I also propose we give someone from the OFED team repo access and they
> can maintain a public branch for ofed-4.8 with any backported fixes.

First of them, they need to express desire :)
Let's start from pull request model and see if it is enough/not enough.

>
> Jason

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: rdma-core release?

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 2238 bytes --]

On 10/12/2016 1:37 PM, Leon Romanovsky wrote:
> On Wed, Oct 12, 2016 at 10:47:59AM -0600, Jason Gunthorpe wrote:
>> On Wed, Oct 12, 2016 at 09:31:49AM -0700, 'Christoph Hellwig' wrote:
>>> On Wed, Oct 12, 2016 at 09:43:08AM -0500, Steve Wise wrote:
>>>> I recommend we release something for OFED-4.8 to pull in.  That
>>>> might help flush out the release process earlier rather than
>>>> later.  Either way, though, I want the latest libcxgb4 in OFED-4.8
>>>> to support the new chelsio HW.  But we talked about the repo being
>>>> "always stable", so I guess the OFA could just pull the code and
>>>> use it?  Still would be nice to have it released...
>>>
>>> Yeah, I'd much prefer to release early, release often.  If people
>>> don't feel quite comfortable with the new bundle yet we can officially
>>> call it a pre-release.
>>
>> One of the best ways to get it tested is to get it to go through the
>> full OFED process.
> 
> No problem, I'll grab all remaining patches from ML tomorrow and we will
> be ready for first release.

I wouldn't mind a pre-release, but I know for a fact that Jarod is
working on proper distro specific spec file(s), systemd units, etc.  So,
I wouldn't call it a release because until we sort out the specifics of
how we want the package to build/look/etc., it might change.  It would
be bad from for release 1 to have things packaged one way, and release 2
to totally revamp that.  We need to give Jarod time to sort through what
he's working on and post it to the list.

>>
>> Woody, what could we do to help make that happen? Do you know of any
>> blocker?
>>
>> I think this will be the best for everyone. I also predict that OFED
>> will be under pressure to quickly take up the new drivers that will
>> land in 4.9, and their user space will live in rdma-core.
>>
>> I also propose we give someone from the OFED team repo access and they
>> can maintain a public branch for ofed-4.8 with any backported fixes.
> 
> First of them, they need to express desire :)
> Let's start from pull request model and see if it is enough/not enough.
> 
>>
>> Jason


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

RE: rdma-core release?

[Woodruff, Robert J]

Jason wrote,
>One of the best ways to get it tested is to get it to go through the full OFED process.

>Woody, what could we do to help make that happen? Do you know of any blocker?

>I think this will be the best for everyone. I also predict that OFED will be under pressure to quickly take up the new drivers that will land in >4.9, and their user space will live in rdma-core.

>I also propose we give someone from the OFED team repo access and they can maintain a public branch for ofed-4.8 with any backported >fixes.

>Jason

We have just started work on OFED-4.8, so there is still a possibility to move to the new tree as the basis for the user-space code that
that goes into OFED. I think that Vlad (who is the OFED integration engineer) was waiting till things were a little more finalized
and wait till all packaging was flushed out before moving to the new code base. I think it would be desirable if there were some kind of official release tar ball or at least official release git tag that is recommended by you guys that we should use in OFED. 
Currently the way OFED handles user-space packages is that we wait till the maintainer of a user-space package produces a release for their user-space component, which is a tar ball with the spec files that can be used to produce SRPMS. 

I have not followed this really closely, but have you guys finalized how the packaging in SRPMs will/should work ? Or is that an exercise left up to the Linux distros and/or OFED to decide on ?

In any case, Vlad is on vacation for a couple weeks, so he probably cannot re-look at this until after Nov 1 when he returns, so you have some time to decide on how you want to handle releases for this.
woody

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core release?

[Jason Gunthorpe]

On Wed, Oct 12, 2016 at 06:17:45PM +0000, Woodruff, Robert J wrote:

> and wait till all packaging was flushed out before moving to the new
> code base. I think it would be desirable if there were some kind of
> official release tar ball or at least official release git tag that
> is recommended by you guys that we should use in OFED.

It is pretty fluid at this point, if OFED says, hey we are happy with
this commit, I'm sure Doug can tag it. I suspect we will produce tar
files out of github, so a tag means a tar will appear.

The current git HEAD should be a suitable starting point for OFED, I
think. It is no worse than what OFED had from the individual tar
files, and contins various important driver updates.

> I have not followed this really closely, but have you guys finalized
> how the packaging in SRPMs will/should work ? Or is that an exercise
> left up to the Linux distros and/or OFED to decide on ?

As Doug touched on this, the distros have to decide based on their own
internal policies how this should look, so we will help but not
dictate. SuSE and CentOS already use quite different packaging and
even different rpm names from what I can see.

What does OFED do, and what do you want? Closeness to current distro
packaging? Closeness to future packaging? Something OFED specific?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: rdma-core release?

[Woodruff, Robert J]

Jason wrote,

>What does OFED do, and what do you want? Closeness to current distro packaging? Closeness to future packaging? Something OFED >specific?

I think this is still a TBD and needs further discussion within the OFA EWG and with Vlad to see what makes the most sense.
We clearly have to comprehend things like upgrading from older versions of OFED and consider things that the Linux distro
might want us to do to make their lives easier, and the answer to that is likely different depending on the Linux distro. 
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma-core release?

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 2081 bytes --]

On 10/12/2016 3:00 PM, Woodruff, Robert J wrote:
> Jason wrote,
> 
>> What does OFED do, and what do you want? Closeness to current distro packaging? Closeness to future packaging? Something OFED >specific?
> 
> I think this is still a TBD and needs further discussion within the OFA EWG and with Vlad to see what makes the most sense.
> We clearly have to comprehend things like upgrading from older versions of OFED and consider things that the Linux distro
> might want us to do to make their lives easier, and the answer to that is likely different depending on the Linux distro. 
> 

For us, this will likely depend on what release you are talking about.
It is very difficult to change package names in the middle of an
existing release.  We try to avoid that if at all possible.  So we will
likely use a spec file that spits out all the same package names people
are used to for EL 7, and wait until our next major release to switch to
the more monolithic package setup.

For someone like OFED this matters too because their scripts have to be
made aware of all possible package names so they know to remove the
inbox packages before they install their own.  For the foreseeable
future, the OFED scripts will have to be aware of both a monolithic
build and a split out build just so it can do the removal successfully.
They are then free to install the packages however they see fit.

There will be some education issues to resolve.  Even though we are
likely to split up the package output on EL 7, there is not a 1 to 1
correspondence.  For example, there will only be one debuginfo package
for the entire build, so people who thought they could do yum install
libmlx4-debuginfo are going to be wondering why it isn't available.  But
there isn't much we can do about that.  Fortunately, it's only the
debuginfo and src rpm that will change this way, we can create all of
the other split out packages so things will look mostly the same way.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: 0E572FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: rdma-core release?

[Jason Gunthorpe]

On Wed, Oct 12, 2016 at 06:15:11PM -0400, Doug Ledford wrote:

> For someone like OFED this matters too because their scripts have to be
> made aware of all possible package names so they know to remove the
> inbox packages before they install their own.  For the foreseeable
> future, the OFED scripts will have to be aware of both a monolithic
> build and a split out build just so it can do the removal successfully.
> They are then free to install the packages however they see fit.

ofed may wish to consider just a very simple monolithic
rdma-core-{libs,devel,bin} which conflicts with all possible distro
package names...

Also, I hope that several of the 'loose' things ofed has like the init
scripts and what not will migrate into rdma-core and be more
consistent across distros. OFED may prefer to patch such things 
into rdma-core than to continue producing 'loose' stuff.

> There will be some education issues to resolve.  Even though we are
> likely to split up the package output on EL 7, there is not a 1 to 1
> correspondence.  For example, there will only be one debuginfo package
> for the entire build, so people who thought they could do yum install
> libmlx4-debuginfo are going to be wondering why it isn't available.  But
> there isn't much we can do about that.  Fortunately, it's only the
> debuginfo and src rpm that will change this way, we can create all of
> the other split out packages so things will look mostly the same way.

That should be doable, I was able to do it for Debian.

Do you think the new providers could go into some kind of combined rpm
in EL 7 with the same name that FC/EL 8 will have?

Ideally I'd like to get to a point where adding new providers is not a
pain point requiring distro approval and eval of new package names/etc.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html