[LU-18761] Handle OBD_OCD_VERSION with potential Lustre 3.X branding

• Type: Improvement
• Resolution: Unresolved
• Priority: Minor
• Environment: latest master
• Severity: 3
• Assignee: James A Simmons
• Reporter: James A Simmons

Description

The roadmap of the upstreaming efforts will include a major rework of the tree. This change has brought up the discussion of relabeling Lustre as 3.0. We have many Lustre version checks in the code that will break in such a case. We need to examine which if these items need to be changed and how to change it to fix Linux kernel standards.

Issue Links

• is related to: LU-9128 remove OBD_OCD_VERSION-ed out code
• is related to: LU-12511 Prepare lustre for adoption into the linux kernel

Comments

[Tim Day]

I think this is referring to a suggestion by Peter - after Lustre gets accepted upstream, declare that release as Lustre 3.0 to indicate to the wider community that we're undergoing a major change. If we did something like that, we don't want to break interop with 2.x releases or unintentional deprecate something too soon. Personally, I don't have a strong opinion about whether we should declare a Lustre 3.0 after upstreaming.

[Andreas Dilger]

I don't think Linux kernel standards apply here, since this has nothing to do with kernel versions.

The OBD_OCD_VERSION checks are about deprecating code in future versions of the Lustre protocol, which is unrelated to the kernel versioning on a single node. People don't complain about NFS having different protocol versions.

Also, the kernel also has mechanisms to deprecate features, filesystems, drivers, etc. in future releases. However, we can't tie the Lustre version to the kernel version.