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

lustre client rebuild not building lnetctl

Details

    • Bug
    • Resolution: Fixed
    • Minor
    • Lustre 2.11.0
    • Lustre 2.10.2
    • None
    • OS: SLF 6.8
      Kernel: 2.6.32-642.15.1.el6.x86_64
    • 3
    • 9223372036854775807

    Description

      Similar to LU-7887.

      lnetctl not present in lustre-client rpm rpm rebuild from source. lnetctl is present in prebuilt rpm.

      It will be extremely helpful to have "rpmbuild --rebuild" to build lustre client rpm with the same content and functionality as lustre-client rpm from distro.

      The lustre client rpm rebuild is required time to time through lifecycle of the cluster. It shall be possible to do this type of work by administrators without knowledge of lustre internals.
      There are several mails on lustre-discuss list reporting lnetctl is not in rpm.

      I had to explicitly use flags as listed below to get lnetctl:
      rpmbuild --rebuild --without servers --with lnet-dlc --with lustre-utils ./lustre-2.10.2-1.src.rpm

      I did not try rpm rebuild for SLF 7.4 as distro version worked for me.

      The other aspect, we have to document rpm rebuild procedure.
      There are clear and detailed instructions on client rebuild on Cray website for their distro. I can not easily find "rebuild" in lustre manual linked from lustre.org.
      There are detailed instructions on lustre wiki; they have to be updated with lnet-dlc lustre-utils until rpm build fixed.

      Attachments

        Issue Links

          Activity

            [LU-10556] lustre client rebuild not building lnetctl

            James Nunez (james.a.nunez@intel.com) uploaded a new patch: https://review.whamcloud.com/31800
            Subject: Revert "LU-10556 build: add require libyaml and zlib"
            Project: fs/lustre-release
            Branch: master
            Current Patch Set: 1
            Commit: 8c206fdb6a2deae0cf60c4da4900518dad8360d4

            gerrit Gerrit Updater added a comment - James Nunez (james.a.nunez@intel.com) uploaded a new patch: https://review.whamcloud.com/31800 Subject: Revert " LU-10556 build: add require libyaml and zlib" Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: 8c206fdb6a2deae0cf60c4da4900518dad8360d4
            pjones Peter Jones added a comment -

            Landed for 2.11

            pjones Peter Jones added a comment - Landed for 2.11

            Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/31710/
            Subject: LU-10556 build: add require libyaml and zlib
            Project: fs/lustre-release
            Branch: master
            Current Patch Set:
            Commit: ab3185eb2b54ed2f616022956dca9bd5a849eb80

            gerrit Gerrit Updater added a comment - Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/31710/ Subject: LU-10556 build: add require libyaml and zlib Project: fs/lustre-release Branch: master Current Patch Set: Commit: ab3185eb2b54ed2f616022956dca9bd5a849eb80

            Alex I have a patch for the gss issues : https://review.whamcloud.com/#/c/3175. That is tracked under LU-10752

            simmonsja James A Simmons added a comment - Alex I have a patch for the gss issues : https://review.whamcloud.com/#/c/3175.  That is tracked under LU-10752

            There is unrelated gss issue on SLF 7 node (it can be also some rpms are installed/missing).

            I had to add flags on SLF7 node to resolve error:

            --define 'configure_args --disable-gss --disable-gss-keyring'

            File not found: /root/rpmbuild/BUILDROOT/lustre-2.11.0_RC1_1_gac4da53-1.x86_64/etc/request-key.d/lgssc.conf

             

            Built completed OK on SLF 6.8 node.

             

            I guess gss is disabled by default in lustre.spec.in . If by some reason gss is enabled lustre build shall provide default on build host or do not complain.

            I read lgssc.conf is not used on client host until gss is configured:

            LUDOC-197:

            • * is the /etc/request-key.d/lgssc.conf file included and installed with the Lustre RPMs? It seems that would be OK, since it would never be used unless there is a security flavor for a connection. The fewer things that users need to configure, the better.

             

             

            alex.ku Alex Kulyavtsev added a comment - There is unrelated gss issue on SLF 7 node (it can be also some rpms are installed/missing). I had to add flags on SLF7 node to resolve error: --define 'configure_args --disable-gss --disable-gss-keyring' File not found: /root/rpmbuild/BUILDROOT/lustre-2.11.0_RC1_1_gac4da53-1.x86_64/etc/request-key.d/lgssc.conf   Built completed OK on SLF 6.8 node.   I guess gss is disabled by default in lustre.spec.in . If by some reason gss is enabled lustre build shall provide default on build host or do not complain. I read lgssc.conf is not used on client host until gss is configured: LUDOC-197 : * is the /etc/request-key.d/lgssc.conf file included and installed with the Lustre RPMs? It seems that would be OK, since it would never be used unless there is a security flavor for a connection. The fewer things that users need to configure, the better.    

            I confirm /usr/sbin/lnetctl present in lustre-client rpm built from  lustre-2.11.0_RC1_1_gac4da53-1.src.rpm

            on SLF 7.4:  3.10.0-693.11.1.el7.x86_64

            and SLF 6.8: 2.6.32-642.15.1.el6.x86_64

             

            I grabbed source rpm from build server (artifact of build triggered by patch 31710)

            wget http://build.lustre.org/downloads/31710/1/centos/7.2/SRPM/lustre-2.11.0_RC1_1_gac4da53-1.src.rpm

            DIR=../downloads/build.lustre.org

            SRPM=lustre-2.11.0_RC1_1_gac4da53-1.src.rpm 

            rpmbuild  --rebuild --without servers --define 'configure_args --disable-gss --disable-gss-keyring' $DIR/$SRPM

             

            alex.ku Alex Kulyavtsev added a comment - I confirm /usr/sbin/lnetctl present in lustre-client rpm built from  lustre-2.11.0_RC1_1_gac4da53-1.src.rpm on SLF 7.4:   3.10.0-693.11.1.el7.x86_64 and SLF 6.8:  2.6.32-642.15.1.el6.x86_64   I grabbed source rpm from build server (artifact of build triggered by patch 31710) wget http://build.lustre.org/downloads/31710/1/centos/7.2/SRPM/lustre-2.11.0_RC1_1_gac4da53-1.src.rpm DIR=../downloads/build.lustre.org SRPM=lustre-2.11.0_RC1_1_gac4da53-1.src.rpm  rpmbuild  --rebuild --without servers --define 'configure_args --disable-gss --disable-gss-keyring' $DIR/$SRPM  

            Minh Diep (minh.diep@intel.com) uploaded a new patch: https://review.whamcloud.com/31710
            Subject: LU-10556 build: add require libyaml and zlib
            Project: fs/lustre-release
            Branch: master
            Current Patch Set: 1
            Commit: ac4da53c0f66b2f77b9f502bac6f4b26a45f2ceb

            gerrit Gerrit Updater added a comment - Minh Diep (minh.diep@intel.com) uploaded a new patch: https://review.whamcloud.com/31710 Subject: LU-10556 build: add require libyaml and zlib Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: ac4da53c0f66b2f77b9f502bac6f4b26a45f2ceb

            Yep. I missed adding that dependency. BTW while working with the LU-9897 patch I noticed Debian/Ubuntu have no dependencies in its build files!!!! I was waiting for Martin's Ubuntu server patches to land first before I fix that.

            simmonsja James A Simmons added a comment - Yep. I missed adding that dependency. BTW while working with the LU-9897 patch I noticed Debian/Ubuntu have no dependencies in its build files!!!! I was waiting for Martin's Ubuntu server patches to land first before I fix that.

            If we are marking the lctl versions of the commands deprecated in 2.11 (per LU-10003) it makes sense to have enable_dlc set by default.

            Alex, if you already have a patch for this, could you please submit it to Gerrit so we can land that for 2.11 and backport it for a 2.10 maintenance release.

            James, I see that in LU-9897 there is a change to the lustre.spec.in file that removes the conditional build of liblnetconfig.so but it doesn't add libyaml or yaml-devel (or whatever) package to the Build-requires: line.  That should probably be added.

            adilger Andreas Dilger added a comment - If we are marking the lctl versions of the commands deprecated in 2.11 (per LU-10003 ) it makes sense to have enable_dlc set by default. Alex, if you already have a patch for this, could you please submit it to Gerrit so we can land that for 2.11 and backport it for a 2.10 maintenance release. James, I see that in LU-9897 there is a change to the lustre.spec.in file that removes the conditional build of liblnetconfig.so but it doesn't add libyaml or yaml-devel (or whatever) package to the Build-requires: line.  That should probably be added.
            alex.ku Alex Kulyavtsev added a comment - - edited

            Yes, both libyaml libyaml-devel installed - I learned that during the server build.
            config log explicitly shows that "configure" got libyaml* during rpm build.

            I rebuilt rpm with / without disable-dlc flag and it made the difference so it is not related to host configuration (with libyaml present).

            config.status shows for the plain rebuild "--without servers" and without explicitly setting flags lnet-dlc that enable_dlc is set no (disabled) by default and this prevents building lnetctl.

            aclocal.m4 :

            # LN_CONFIG_DLC
            #
            # Configure dlc if enabled
            #
            # if libyaml is set (IE libyaml installed) and enable_dlc = yes then build
            # dlc other wise (IE if libyaml is not set or enable_dlc = no) then don't
            # build dlc.
            

            Because distro rpm has dlc enabled, we shall have set enable_dlc = yes by default (at least when libyaml installed) and explicitly disable dlc when it is not needed and/or libyaml not installed.

            At this point I'm OK with workaround;

            It is important to have client rpm to be rebuild with the same configuration as rpm in distro without unpacking and digging into source rpm.

            alex.ku Alex Kulyavtsev added a comment - - edited Yes, both libyaml libyaml-devel installed - I learned that during the server build. config log explicitly shows that "configure" got libyaml* during rpm build. I rebuilt rpm with / without disable-dlc flag and it made the difference so it is not related to host configuration (with libyaml present). config.status shows for the plain rebuild "--without servers" and without explicitly setting flags lnet-dlc that enable_dlc is set no (disabled) by default and this prevents building lnetctl. aclocal.m4 : # LN_CONFIG_DLC # # Configure dlc if enabled # # if libyaml is set (IE libyaml installed) and enable_dlc = yes then build # dlc other wise (IE if libyaml is not set or enable_dlc = no) then don't # build dlc. Because distro rpm has dlc enabled, we shall have set enable_dlc = yes by default (at least when libyaml installed) and explicitly disable dlc when it is not needed and/or libyaml not installed. At this point I'm OK with workaround; It is important to have client rpm to be rebuild with the same configuration as rpm in distro without unpacking and digging into source rpm.

            People

              simmonsja James A Simmons
              alex.ku Alex Kulyavtsev
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: