[
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)
