[lustre-discuss] lustre vs. lustre-client

[Alexander I Kulyavtsev]

What about lustre client in upstream kernel? 
I guess lustre-common and lustre-client shall be packaged in a way that these rpms can be drop-in replacement for lustre client functionality in upstream kernel like today we have lustre with in-kernel IB or custom IB.

Also there was  discussion to split off lnet rpm.

“only a handful of modules would be different between the client and server”
Do these extra server modules bring extra dependencies like zfs or else? 

Alex.


On 8/10/18, 5:36 PM, "Andreas Dilger" <adilger at whamcloud.com> wrote:

    On Aug 9, 2018, at 18:51, Faaland, Olaf P. <faaland1 at llnl.gov> wrote:
    > 
    > Hi,
    > 
    > What is the reason for naming the package "lustre" if it includes both client and server binaries, but "lustre-client" if it includes only the client?
    > 
    > ===== (from
    > # Set the package name prefix
    > %if %{undefined lustre_name}
    >    %if %{with servers}
    >        %global lustre_name lustre
    >    %else
    >        %global lustre_name lustre-client
    >    %endif
    > %endif
    > =====
    > 
    > Are there sites that build both with and without servers, and need to keep track which is installed on a given machine?  The size of the RPMs isn't that different, so it's not obvious to me why one would do that.
    
    The original reason for separate "lustre" and "lustre-client" packages was
    that the "lustre-client" package was built against a patchless kernel, so
    that it could be installed on unmodified client systems.  At the time, this
    was a departure from the all-inclusive "lustre" package that was always
    built against a patched kernel.
    
    Until not so long ago, it wasn't possible to build a server against an
    upatched kernel, but that has been working for a while now.  We do build
    "patched" and "unpatched" server RPMs today, but haven't gotten around to
    changing the packaging to match.
    
    At this point, I think it makes sense to just move over to RPMs for patched
    and unpatched kernels, and get rid of the "-client" package.  Alternately,
    we could have "lustre-client", "lustre-server", and "lustre-common" RPMs,
    but (IMHO) that just adds more confusion for the users, and doesn't really
    reduce the package size significantly (only a handful of modules would be
    different between the client and server).
    
    Having a patched server kernel isn't needed for ZFS, and while it works for
    ldiskfs as well, there are still a few kernel patches that improve ldiskfs
    server performance/functionality that are not in RHEL7 (e.g. project quota,
    the upcoming T10-PI interface changes) that make it desirable to keep both
    options until those changes are in vendor kernels.
    
    Cheers, Andreas
    ---
    Andreas Dilger
    Principal Lustre Architect
    Whamcloud