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

Lustre init scripts with heartbeat v1 integration

Details

    • Improvement
    • Resolution: Fixed
    • Minor
    • Lustre 2.3.0
    • Lustre 2.1.0
    • None
    • 20,165
    • 4555

    Description

      This issue is to request that Lustre initialization scripts developed at LLNL be reviewed for inclusion in Lustre. A Gerrit submission for review is on its way.

      Attachments

        Issue Links

          Activity

            [LU-107] Lustre init scripts with heartbeat v1 integration

            Cory and/or Ned, could you please submit a patch to resolve this issue.

            adilger Andreas Dilger added a comment - Cory and/or Ned, could you please submit a patch to resolve this issue.
            spitzcor Cory Spitz added a comment -

            Ned Bass was right, people who have a preexisting /etc/init.d/lustre will be in trouble.

            That is unless there was already a site-specific /etc/init.d/lustre script in place and we overwrite it. The safest thing to do may be to mark it %config(noreplace) in the spec file.

            That wasn't done when this landed for 2.3, so it has broken Cray's environment. (besides the other issues that Wally raised)
            We can probably live with it, but maybe the Ops Manual should be updated to warn the installer.

            spitzcor Cory Spitz added a comment - Ned Bass was right, people who have a preexisting /etc/init.d/lustre will be in trouble. That is unless there was already a site-specific /etc/init.d/lustre script in place and we overwrite it. The safest thing to do may be to mark it %config(noreplace) in the spec file. That wasn't done when this landed for 2.3, so it has broken Cray's environment. (besides the other issues that Wally raised) We can probably live with it, but maybe the Ops Manual should be updated to warn the installer.

            Please reopen this ticket if there is outstanding work to do.

            jlevi Jodi Levi (Inactive) added a comment - Please reopen this ticket if there is outstanding work to do.

            We have our own make/spec to build for our environment but I think you should run into the same problem using 'make rpm' in SLES11.

            wang Wally Wang (Inactive) added a comment - We have our own make/spec to build for our environment but I think you should run into the same problem using 'make rpm' in SLES11.

            Hi Wally,

            Thanks for reporting these problems. We knew the init scripts would probably need work to properly support non-redhat distros. I don't currently have a SLES system to test on, but when I get a chance I'll try to bring up a VM to look into this.

            Are you just using 'make rpm'?

            nedbass Ned Bass (Inactive) added a comment - Hi Wally, Thanks for reporting these problems. We knew the init scripts would probably need work to properly support non-redhat distros. I don't currently have a SLES system to test on, but when I get a chance I'll try to bring up a VM to look into this. Are you just using 'make rpm'?

            When we do our packaging on SLES11 SP1/2, we run into the following problems:

            1. no LSB header information:

            E: File `lnet' without LSB header found in /var/tmp/cray-lustre-cray_gem_c-2.3_3.0.34_0.7.9_1.0000.6718.11.1-root/etc/init.d/
            E: File `lustre' without LSB header found in /var/tmp/cray-lustre-cray_gem_c-2.3_3.0.34_0.7.9_1.0000.6718.11.1-root/etc/init.d/

            2. need sysconfig.lustre in /var/adm/fillup-templates:

            cray-lustre-cray_gem_c: "/etc/sysconfig/lustre" is not allowed anymore in SuSE Linux.

            3. if failover is only for servers, it should probably be excluded from client build

            wang Wally Wang (Inactive) added a comment - When we do our packaging on SLES11 SP1/2, we run into the following problems: 1. no LSB header information: E: File `lnet' without LSB header found in /var/tmp/cray-lustre-cray_gem_c-2.3_3.0.34_0.7.9_1.0000.6718.11.1-root/etc/init.d/ E: File `lustre' without LSB header found in /var/tmp/cray-lustre-cray_gem_c-2.3_3.0.34_0.7.9_1.0000.6718.11.1-root/etc/init.d/ 2. need sysconfig.lustre in /var/adm/fillup-templates: cray-lustre-cray_gem_c: "/etc/sysconfig/lustre" is not allowed anymore in SuSE Linux. 3. if failover is only for servers, it should probably be excluded from client build

            If a site hasn't configured /etc/ldev.conf then adding the /etc/init.d/lustre script should have no effect.

            That is unless there was already a site-specific /etc/init.d/lustre script in place and we overwrite it. The safest thing to do may be to mark it %config(noreplace) in the spec file.

            nedbass Ned Bass (Inactive) added a comment - If a site hasn't configured /etc/ldev.conf then adding the /etc/init.d/lustre script should have no effect. That is unless there was already a site-specific /etc/init.d/lustre script in place and we overwrite it. The safest thing to do may be to mark it %config(noreplace) in the spec file.

            Doug,
            could you please have a look at how the patch in http://review.whamcloud.com/290 complements or conflicts with your proposed changes to LNET configuration. I believe you were already planning to start with an /etc/init.d/lnet startup file. Hopefully by landing this now, it will give you a starting point for your configuration changes, and users will already be aware of this script, so your changes will be transparent to them.

            adilger Andreas Dilger added a comment - Doug, could you please have a look at how the patch in http://review.whamcloud.com/290 complements or conflicts with your proposed changes to LNET configuration. I believe you were already planning to start with an /etc/init.d/lnet startup file. Hopefully by landing this now, it will give you a starting point for your configuration changes, and users will already be aware of this script, so your changes will be transparent to them.

            Hi Andreas,

            If a site hasn't configured /etc/ldev.conf then adding the /etc/init.d/lustre script should have no effect. That is, it won't start any services or interfere with whatever method was used to start lustre before updating. Also it not run by the init system by default, but rather it is intended to by started by a HA/failover mechanism such as heartbeat.

            /etc/init.d/lnet could start lnet sooner than was the case before updating, but I wouldn't expect that to break anything.

            nedbass Ned Bass (Inactive) added a comment - Hi Andreas, If a site hasn't configured /etc/ldev.conf then adding the /etc/init.d/lustre script should have no effect. That is, it won't start any services or interfere with whatever method was used to start lustre before updating. Also it not run by the init system by default, but rather it is intended to by started by a HA/failover mechanism such as heartbeat. /etc/init.d/lnet could start lnet sooner than was the case before updating, but I wouldn't expect that to break anything.

            Ned, Brian, are there any implications to an existing system if /etc/init.d/lustre and /etc/init.d/lnet are suddenly added to an existing system?

            What we don't want is that someone upgrades to Lustre 2.4 from 2.1 and suddenly their system is unusable until they generate an /etc/ldev.conf or something. My assumption is that nobody ever reads the manual or release notes when upgrading, so if it doesn't work correctly "out of the box" then something was done incorrectly by the code(r).

            adilger Andreas Dilger added a comment - Ned, Brian, are there any implications to an existing system if /etc/init.d/lustre and /etc/init.d/lnet are suddenly added to an existing system? What we don't want is that someone upgrades to Lustre 2.4 from 2.1 and suddenly their system is unusable until they generate an /etc/ldev.conf or something. My assumption is that nobody ever reads the manual or release notes when upgrading, so if it doesn't work correctly "out of the box" then something was done incorrectly by the code(r).

            People

              green Oleg Drokin
              nedbass Ned Bass (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: