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

["Jinmei Liao (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-8403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jinmei Liao resolved GEODE-8403.
--------------------------------
    Resolution: Duplicate

> 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
>    Affects Versions: 1.12.1, 1.13.0, 1.14.0
>            Reporter: Bill Burcham
>            Priority: Major
>              Labels: GeodeOperationAPI
>
> 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()}})



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