[LU-7976] sles builds severely impacted by recent naming changes

• Status: Resolved
• Project: Lustre
• Type: Bug
• Priority: Critical
• Reporter: Bob Glossman (Inactive)
• Assignee: Bob Glossman (Inactive)
• Resolution: Not a Bug
• Severity: 3

Description

It now appears that the recent landing of the mod for "LU-7699 build: Replace version_tag.pl with LUSTRE-VERSION-GEN" has had bad side effects on build and test for any sles version. Bad effects have been seen in both sles11sp3 and sles11sp4.

One effect is lustre-osd-ldiskfs-mount no longer gets installed automatically. The requires string in lustre-osd-ldiskfs doesn't match the provides string in lustre-osd-ldiskfs-mount.

lustre-osd-ldiskfs-mount provides says:
lustre-osd-ldiskfs-mount = 2.8.51_3_g8062fbb-3.0.101_71_lustre_default

lustre-osd-ldiskfs requires says:
lustre-osd-ldiskfs-mount = 2.8.51_3_g8062fbb

They don't match. Before the landing of LU-7699, they did match.

rpm names now are inconsistent in any sles build. some examples:

lustre-modules-2.8.51_3_g8062fbb-3.0.101_71_lustre_default
kernel-default-3.0.101-71_lustre

lustre rpms have '3.0.101_71_lustre_default" in the name
kernel rpms have "3.0.101-71_lustre" in the name

some or all of these unexpected side effects of the name changes block our normal automatic build/test flow on any SLES versions.

Issue Links

• is related to: LU-7699 Overhaul lustre's versioning

Comments

[Christopher Morrone]

lustre-osd-ldiskfs-mount provides says:
lustre-osd-ldiskfs-mount = 2.8.51_3_g8062fbb-3.0.101_71_lustre_default

lustre-osd-ldiskfs requires says:
lustre-osd-ldiskfs-mount = 2.8.51_3_g8062fbb

What did they look like previously? It is not immediately obvious to me that these are actually mismatched. The one package requires a particular Version, and the other provides said Version. Granted, the "Provides" includes the Release as well, but as far as I know that should not break Version matching.

The patch did not directly change the Provides or Requires for those patches, either. There was indirect change because the git describe information moved from the Release to the version. But it would not have changed the fact that one Provides Version-Release, and the other just Requires Version.

I'm a little confused about what has actually gone wrong. Can you please post the explicit errors that you are seeing?

rpm names now are inconsistent in any sles build. some examples:

lustre-modules-2.8.51_3_g8062fbb-3.0.101_71_lustre_default
kernel-default-3.0.101-71_lustre

lustre rpms have '3.0.101_71_lustre_default" in the name
kernel rpms have "3.0.101-71_lustre" in the name

Can you provide a longer list of the employed sles kernel packages? "rpm -qi" on the main package would also be helpful.

It is not immediately clear to me how the "default" string is jumping out of the kernel package name and landing at the end of Lustre's Release field. I don't remember writing any special code to do that. It seems more likely that the kernel really does have "-default" in its version somewhere.

[Bob Glossman (Inactive)]

Chris,
i think the idea about provides/requires strings not matching is a red herring. It now seems more likely that the sles provisioning problems we've been observing lately are not due to the naming changes in package names or versions, but to other recent build changes.

Once I know for sure it's likely this bug will be closed out.

[Christopher Morrone]

OK, then I won't look into this further for now. If you later find out that it is related to the version changes, just let me know. I'm happy to keep working on it until we find something that works well enough everywhere we need it.

[Bob Glossman (Inactive)]

The actual build problem isn't at all the one imagined and described here. Closing this bug. See LU-8023 for the real problem.