Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-14680

remove strict dependency between user tools and kernel RPMs

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Rank (Obsolete):
      9223372036854775807

      Description

      There is currently a strong linkage between the userspace tools and the kernel modules, in lustre.spec.in:

      Requires: %{requires_kmod_name} = %{requires_kmod_version}
      

      and this evaluates to a very specific kernel module package version, e.g.:

      kmod-lustre-client = 2.14.0_7_gf7512cc
      

      This dates back to commit 1.6.0-2717-gc7496eccfc, but that doesn't provide much explanation beyond "Tighten up some dependencies.", and the b=13908 is no longer available:

      commit c7496eccfc6a4bc804bd999343a2d289d5e9eeaf
      Author:     brian <brian>
      AuthorDate: Wed Apr 22 17:55:29 2009 +0000
      Commit:     brian <brian>
      CommitDate: Wed Apr 22 17:55:29 2009 +0000
      
          b=13908
          i=yibin.wang
          i=sheng.yang
          
          Allow the name, version, kernel release and release of the lustre packages
          to be defined on the command line.
          With such a feature, actually properly name the patchless client packages in
          our own build.
          Tighten up some dependencies.
      

      Such a strong binding between the user tools and the kernel modules is not really needed and could be relaxed significantly. Sticking within the same major release (e.g. ">= 2.14.0" in this case) would almost certainly be enough, with the caveat that not having new tools may limit access to some functionality that is available in the kernel (e.g. missing an "lfs" or "lctl" command to enable something, or an llapi_* function that was added later.

      In theory, newer tools could also handle significantly older kernel module versions to some extent, but would typically be lacking in features from a newer release. In that regard, it doesn't really make sense for the user tools to require a newer version, but rather the kernel modules should require at least a minimum version of the tools in order to enable the new functionality. That said, maintaining some level of coherency between the tools and kernel modules makes sense, maybe within a few major release versions (+/- 0.3) to allow old interfaces to be slowly deprecated as needed.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              wc-triage WC Triage
              Reporter:
              adilger Andreas Dilger
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated: