Details
-
Bug
-
Resolution: Fixed
-
Major
-
Lustre 2.4.0
-
Builds from the build server
-
3
-
7569
Description
While working on LU-3109 it seems the ZFS we package is old.
Christopher Morrone added a comment - 05/Apr/13 1:04 AM rc10 is old, you should definitely upgrade to the latest rc of 0.6.0. 0.6.1 is a little TOO new, because packaging has changed there, and lustre will need a little tweaking to find the new paths and things automatically. You can build by hand by giving spl and zfs paths, but the latest 0.6.0 rc will just be easier.
It seems we need to say current with the ZFS version.
Attachments
Activity
I agree. From my point of view it would be ideal if you just added the ZFS repository to your builder image. The benefits would be:
1) ZFS won't need to be rebuilt for each Lustre build.
2) ZFS will be automatically rebuild for kernel upgrades in the image.
3) ZFS will get updated via 'yum update' as stable release are tagged.
(It would be nice if you could setup a proxy to cache the packages locally,
but since you shouldn't need to build them often it's not critical.)
The original patch I posted has support for building against the DKMS style packages from the repository so you should just need to patch Lustre, install the packages in the images, and disable the lbuild ZFS infrastructure. The one gotcha I can think of offhand is that we're not distributing packages for 32-bit systems until some ZFS specific issues get resolved.
Chris, I'm all for having the builders install zfs from a remote repository and just build against it. I think that would be a much better solution. (This is my first foray into the world of lbuild).
Andreas, Do you think we should reopen TT-391 (zfs packages installed on builders), have zfs-dkms-0.6.1 installed on all builders and then add a link to the zfs yum repository (mirroring it locally for installers)?
Chris, in the past we didn't have DKMS packages for ZFS, so we had to build our own. Since we cannot distribute the binary packages, it makes sense to use the DKMS packages if we can use those in our testbed.
Nathaniel, think about it this way: You are modifying an rpm spec file, which means that you are in an rpm environment. However, your patch is explicitly to subvert the rpm way of building packages.
I understand why you are trying to do this, and I can certainly commiserate. The fundamental problem is that the Intel Lustre build farm lacks any system to recognize and honor rpm dependecies.
But while I understand, I don't feel like we should condone that bad behavior of the build farm by adjusting zfs to make it easier to behave badly.
By Lustre 2.5, I very much hope to see the build farm improved to handle rpms in a more reasonable fashion. In the mean time, perhaps you can put the workaround at the source of the problem (i.e. the build farm).
Why do you guys want to build spl/zfs at all? Why not simply install the spl/zfs packages? DKMS versions of the spl/zfs packages are available.
Setup pull request for ZFS https://github.com/zfsonlinux/zfs/pull/1413 to add ability to override spl directory passed to configure during rpm creation.
Structure of the zfs spec files makes it hard to override the location of spl directory during build in zfs 0.6.1
I've worked with Chris to update the zfs & spl versions in the build system to 0.6.1. This will probably break builds until this patch is landed with a fix to the lbuild script for the new versions of zfs and spl.
The change in the new version that caused lbuild to fail is the removal of all the autotools products. The fix in the patch is to run autogen.sh before trying to call configure.
Two more thoughts related to this:
- It would be ideal if you could add the ZFS EPEL repository to your builders. This way with minimal effort you'll always be testing the latest tagged release. Just run 'yum update' and if there are new packages they will be built and installed.
- Longer term if DKMS style packaging is added to Lustre it could be easily hosted in a yum repository like ZFS.
The packaging changes which effect the Lustre build system are the only concern. My intention is to push a patch today which addresses these issues. If we can get this merged before 2.4 is tagged then people will be able to run ZFS 0.6.1 with Lustre 2.4.0 easily. The intention is RHEL/Centos users can add ZFS+Lustre support as follows:
# Install the ZFS EPEL repository and install the ZFS DKMS packages. sudo yum localinstall --nogpgcheck http://archive.zfsonlinux.org/epel/zfs-release-1-2.el6.noarch.rpm sudo yum install zfs zfs-devel # Build and install Lustre as usual, it will automatically detect the ZFS packages and enable OSD support. cd lustre sh autogen.sh ./configure make rpm
Nathaniel, I'm all for improving the build system, and installing extra DKMS packages, but the existing ZFS binary packages cannot be removed until your patch is landed, or it will break other patches in flight. There is a non-zero risk that this change would cause the existing builds or tests to fail in some way, so this change needs to be coordinated with Chris Gearing. I would suggest to open a new bug instead of reusing the old one.