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

["Bill Burcham (Jira)" <ji...@apache.org>]

Bill Burcham created GEODE-8403:
-----------------------------------

             Summary: gfsh connect uses marketing version instead of serialization version in compatibility check
                 Key: GEODE-8403
                 URL: https://issues.apache.org/jira/browse/GEODE-8403
             Project: Geode
          Issue Type: Bug
          Components: gfsh
            Reporter: Bill Burcham


After GEODE-8331 {{ConnectCommand.connect()}} uses the result from {{OperationInvoker.getRemoteVersion()}}, the "marketing" version string, 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. 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()}})



--
This message was sent by Atlassian Jira
(v8.3.4#803005)