[CentOS-devel] No Storage SIG Meeting 6-March-2015 15:30 UTC (Moving it to next week)

On 18 Apr 2015, at 17:36, Doug Ledford <dledford at redhat.com> wrote:
> On Sat, 2015-04-18 at 15:09 +0100, Justin Clift wrote:
>> On 18 Apr 2015, at 10:39, Bart Van Assche <bart.vanassche at sandisk.com> wrote:
>>> On 03/11/15 18:01, Justin Clift wrote:
>>>> On 10 Mar 2015, at 11:09, Bart Van Assche <bart.vanassche at sandisk.com> wrote:
>>>>> Hello,
>>>>> 
>>>>> Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ?
>>>> 
>>>> The "take a risk X might break" bit doesn't really sound suitable
>>>> for the CentOS audience.
>>>> 
>>>> That being said... how often does the RDMA ABI change?  If it's
>>>> once every X years, then it might be live-able (with sufficient
>>>> catches/warning so users aren't affected).
>>> 
>>> (back from traveling - sorry for the delay in replying)
>>> 
>>> Hello Justin,
>>> 
>>> So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ...
>> 
>> Hmmmm... in general RHEL has an attitude of "don't change ABI in
>> updates",
> 
> It's not an attitude, it's a hard requirement that requires managerial
> approval for an exception to break it.
> 
>> but RDMA may or may not have different assumptions.  I
>> have no idea. ;)
> 
> It does.  We exempt the kernel portion of the RDMA stack from any ABI
> claims entirely.  For user space, we make a best effort to preserve
> backward binary compatibility, but not forward.  Meaning if you compile
> a user space app against 7.0, our 7.1 and later updates will all be
> backward compatible to your compiled program.  However, we add
> extensions, so if you compile against 7.2 let's say, and use one of the
> new extensions, then you program will not run on 7.0.  However, keep in
> mind that this is a best effort.  On occasion, with managerial approval,
> we break this too.  The RDMA simply moves too fast to keep it static
> through the life of a RHEL product.

Thanks Doug. :)

+ Justin

--
GlusterFS - http://www.gluster.org

An open source, distributed file system scaling to several
petabytes, and handling thousands of clients.

My personal twitter: twitter.com/realjustinclift