Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-1199 lustre build system overhaul
  3. LU-3464

Create lustre-client and lustre-server binary rpms

    XMLWordPrintable

Details

    • Technical task
    • Resolution: Duplicate
    • Minor
    • None
    • Lustre 2.5.0
    • None
    • 8661

    Description

      I think it would be advantageous to start building separate lustre-client and lustre-server binary rpms as part of our normal build process. There are a couple of reasons why I think this is the way to go, despite the fact that the rpm count is certainly growing large.

      1. Current lustre-client-* vs lustre-* package names are confusing. lustre-* actually contains client code as well. lustre-client-* binary rpms are just lacking the server code. And the lustre-client-<version>.src.rpm is not lacking the server code, which is more confusing still!
      2. A Linux distro can contain one version of lustre, and allow admins to select client and/or server components at install time. Our current build does not allow that. This means that places like LLNL wind up with server init scripts installed on client nodes. Less than optimal.

      This would also be a great opportunity to fix the terribly bad "is_client" macro in the lustre spec file. "is_client" does not really control whether client code is built, instead it controls whether server code is build. And even more confusingly, it shouldn't really be set directly; the proscribed method of selecting a client-only build of lustre is to change the package name to a special string. Not a good design.

      That should be cleaned up as part of the modifications to create the lustre-client- and lustre-server- rpms.

      Attachments

        Issue Links

          Activity

            People

              mdiep Minh Diep
              morrone Christopher Morrone (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: