[LU-9541] repodata still has zfs, which is removed from build artifacts

• Status: Resolved
• Project: Lustre
• Type: Bug
• Priority: Trivial
• Reporter: Stephen Champion
• Assignee: Nathaniel Clark
• Resolution: Won't Fix

Environment

CentOS 7.3 + ZFS

• Severity: 3

Description

I just tried pulling the most recent artifacts from the lustre-mr branch on build.hpdd.intel.com, and installing them with ZFS servers.

It looks like the repodata in the build artifacts contains several ZFS packages, although you the actual ZFS packages are not included in the artifacts (for licensing reasons, I presume).

I expect this is true for other branch builds as well. I just started using ZFS, and have no experience with this on other branches.

Trivial workaround : rebuild the repodata after downloading the artifacts.
Trivial Fix: build the repodata after removing the zfs packages

Comments

[Peter Jones]

Steve

Yes this is deliverate there is a possible licensing incompatability between CDDL and GPL that is being avoid

Narthaniel

Any other pointers that might be useful to Steve?

Peter

[Nathaniel Clark]

There have recently (within the last week) been changes to which packages are available from build.hpdd.intel.com. All the userspace ZFS packages are now directly downloadable. Just the ZFS/SPL kernel modules packages (kmod-spl* and kmod-zfs*) are not distributable. You can use the zfs-dkms and spl-dkms package instead (though then you should also use lustre-dkms).

[Minh Diep]

schamp, for now use 'Trivial workaround : rebuild the repodata after downloading the artifacts.'

[Stephen Champion]

For background: I noticed this when I downloaded build artifacts for testing, then tried to install both Lustre and ZFS. yum parsed repodata and tried to install ZFS from the Lustre repo. Of course, this failed because the file are not actually in the repository.

I expect this state will persist with the kmod repos, unless the sequence is changed.

Some feedback indirectly related to this report: I think providing anything other than a zfs src rpm for the kmod packages is more trouble than it's worth. The user has to build or download something, since we aren't pushing all of the kmod binaries.

If the user tries to use the zfsonlinux kmod repo, having the ZFS userland in both repos may result in a mismatched installation or unnecessary conflicts. If they rebuild the SPL and ZFS packages from the .src.rpm, they also get the ZFS userland, and now have two copies of the userland, one of which is from a different build environment than their modules.