[GEODE-8403] gfsh connect uses marketing version instead of serialization version in compatibility check

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: 1.12.1, 1.13.0, 1.14.0
• Component/s: gfsh
• Labels: GeodeOperationAPI
• Assignee: Unassigned
• Reporter: Bill Burcham
• Created: 04/Aug/20 18:45
• Updated: 28/Sep/20 17:13
• Resolved: 28/Sep/20 17:13

Description

After GEODE-8331 ConnectCommand.connect() uses the result from OperationInvoker.getRemoteVersion(), the "marketing" version string derived from GemFireVersion.getGemFireVersion(), to determine compatibility (with the remote Geode system.)

This is wrong because the purpose of that marketing version string is to carry version info for products derived from Geode. Those product versions do not, in general, correspond to Geode product versions. GemFireVersion.getGemFireVersion() might return values like:

• Apache Geode 1.10
• Pivotal GemFire 9.5
• Ampool Active Data Store 1.0

For compatibility purposes between Geode components, serialization version Version.CURRENT (soon to be KnownVersion.CURRENT) should be used.

The marketing version is set during a build via Gradle -Pversion=<real-version> -PgeodeVersion=<real-version>. Unfortunately, PR pipeline builds do not have those properties set. As a result, such a build will run with marketing version "0.0.0".

Since ConnectCommand.connect() fails (with an error message: Cannot use a 0.0.0 gfsh client to connect to a 0.0.0 cluster for any remote (marketing) version below 1.10 (9.9) gfsh connect won't work on these PR pipeline builds, when connecting to a locator running the same build.

It would be nice if we could fix this by having ConnectCommand.connect() probe the remote version via OperationInvoker.getRemoteGeodeSerializationVersion() instead of OperationInvoker.getRemoteVersion(). But unfortunately, getRemoteGeodeSerializationVersion() was introduced in 1.12 (in GEODE-5194)—it's not present in [1.10,1.12). So the solution isn't so simple.

When this story is complete ConnectCommand.connect() will use this algorithm to determine compatibility with the remote system:

1. try getRemoteGeodeSerializationVersion() and if it succeeds use that for the version comparison
2. if that doesn't work, fall back to OperationInvoker.getRemoteVersion()

This will allow a gfsh built via the PR pipeline to connect to Geode locators built in the same build. For testing with older Geode versions we can rely on those old versions to have been built with -Pversion=<real-version> -PgeodeVersion=<real-version> or to be 1.12-or-newer (and so, to support getRemoteGeodeSerializationVersion())

Issue Links

• is duplicated by: GEODE-8435 restore gfsh ability to connect if serialization versions match regardless of product version
• is related to: GEODE-8331 allow GFSH to connect to newer and older locator/server
• is related to: GEODE-5194 Relax Gfsh version checking on connect, allow connecting to different patch versions