[LU-1476] configure not enforcing tag == version

• Status: Resolved
• Project: Lustre
• Type: Bug
• Priority: Minor
• Reporter: Brian Murrell (Inactive)
• Assignee: WC Triage
• Resolution: Low Priority
• Severity: 3

Description

During the RC build for 2.1.2 the lustre version update was forgotten. There used to be code in configure which detected exactly such a mistake and broke the build because of it. It was put there for exactly this situation. c487014a39a6e37dc22a957aad9ad9b739e3c8cf was landed for LU-278 which changed this error into a warning, of course, hiding the breakage.

Indeed, it is always nice when manual processes (such as incrementing the bits for a new release) go off without a hitch, but having checks to make sure we do them all is probably even better.

I'm still not convinced that the claims of the problems that were being made about that version/tag check in LU-278 were all true but it seems a patch was landed anyway. That is, I'm not convinced that any old tag on a branch would cause configure to error out as was being claimed since the format of tags being looked at is pretty strict.

I propose that the claims in LU-278 be verified as either true or not and if found to be untrue, reverting c487014a39a6e37dc22a957aad9ad9b739e3c8cf so that we don't have this problem in the future.

An alternative would be to add (yet) another switch to configure which toggles whether the checking code is to produce a warning or an error, defaulting to a warning. We could then add that switch to our jenkins build steps so that a tag/version mismatch produce a configure error for our builds causing the build to fail.

Comments

[Andreas Dilger]

I hit the problem in LU-278 several times, as did LLNL. The problem is when there is some other local tag that appears to be a valid tag, but doesn't exactly match the build version. The LLNL tag that failed was "2.0.59-1morrone", and the build version was 2.0.59:

checking for buildid... configure: error: most recent tag found: 2.0.59-1morrone does not match current version 2.0.59

Since we already have special build rules for release versions (removing the git hash from the version string), it makes sense to special-case the "tag must match build version" rule as well, so that normal users are not affected by it.

[Brian Murrell (Inactive)]

Looking at the source for that code the only tags that are considered for that check must match:

ver=$(git describe --match v[[0-9]][[0-9]] --tags)

which is the m4 escaped regex "v[0-9]*[0-9]". So a tag of "2.0.59-1morrone" would not match. Neither would the "very_fine_patch" or "10_things_I_hate_about_autoconf" examples that were used in LU-278.

The fix for that was landed in 3bf2ba3f3aa847e6d5ea9e0653e853aad0f4b95b specifically for LU-278.

So as long as others didn't use that very specific tag format, they are safe.

However, if we wanted to be even more flexible and allow the use that format with additional bits appended to it like the LU-278 example: "2.0.59-1morrone" (which would not match any more so let's contort the example to something that would and call it "v2_0_59-1morrone") a simple patch to the existing code could truncate anything after our standard versioning tag format.

Ultimately, I think the specific tag format that we look for now is narrow enough (and could even allow for appendages per above) that it doesn't seem unreasonable to reserve that format for our own use.

Since we already have special build rules for release versions (removing the git hash from the version string), it makes sense to special-case the "tag must match build version" rule as well, so that normal users are not affected by it.

That special "release versions" code to remove the git hash is in fact all part and parcel of this code that we are discussing so there is really no "other" code that this tag/version comparison feature can become part of.