>> any test starting a peer cache using an old version of Geode must create its own old-version Locator Bruce, we don't allow/recommend starting old versions of locator or peers when the rolling upgrade is started, right?
-Anil. On Thu, Jan 19, 2017 at 11:06 AM, Bruce Schuchardt <bschucha...@pivotal.io> wrote: > One way to do this would be to have the DUnit Locator run the oldest > version of Geode that we want to test with. For now that would be > 1.0.0-incubating. Any test that needs to exercise newer algorithms > involving a Locator would need to launch one of its own. > > Does that sound acceptable? > > Le 1/19/2017 à 9:27 AM, Bruce Schuchardt a écrit : > >> Thanks Dan. I'm not sure we want to keep the change I made to the >> Locator. The restriction on letting old-version members join is for >> rolling upgrade and has been in Geode & GemFire for a long time. It gives >> us some assurance that we can enable new distributed algorithms and stop >> using old algorithms. We ran into that requirement when we altered >> distributed locking behavior in GemFire. >> >> If I revert that change it will require that any test starting a peer >> cache using an old version of Geode must create its own old-version >> Locator. That's probably the best thing to do because the way I have it >> right now might make it very hard to implement new algorithms that involve >> the Locator. If an old-version peer starts up and the Locator sends it a >> message it doesn't comprehend, or the Locator expects it to do something >> and it doesn't, it could be difficult to deal with. >> >> Le 1/19/2017 à 9:07 AM, Dan Smith a écrit : >> >>> +1 This is great Bruce! I really like this approach of being able to >>> write >>> tests and have them run with some members with a different version. I >>> think >>> with this framework we should be able to just extend existing tests with >>> subclasses that override the version of some of the VMs which I think is >>> a >>> good way to do the backwards compatibility testing. >>> >>> One question - you modified the locator to allow old versions to join. >>> Why >>> was that necessary? I know we broke P2P compatibility between gemfire 8 >>> and >>> geode 1.0, but are we not allowing P2P compatibility going forward? I was >>> under the impression that 1.1 was going to be compatible with 1.0. Is >>> that >>> not the case? Why do the tests need to have peers with different versions >>> if we are not supporting that? Is there a way we can do these tests >>> without >>> having the product code behave differently when it is being tested than >>> when it is being used normally? >>> >>> -Dan >>> >>> >>> >>> On Wed, Jan 18, 2017 at 3:11 PM, Bruce Schuchardt < >>> bschucha...@pivotal.io> >>> wrote: >>> >>> I've extended the distributedTest framework to let us do >>>> backward-compatibility testing. Once it is reviewed and committed >>>> people >>>> will be needed to modify existing tests to run against multiple >>>> versions of >>>> Geode. >>>> >>>> Here is the RB review: https://reviews.apache.org/r/55688/ >>>> >>>> The diff in this review includes a client/server test modified to run >>>> against multiple versions. Basically you just need to parameterize an >>>> existing distributedTest case to run against multiple versions using >>>> Host.getHost(0).getVM(testVersion, vmNumber). That give you a JVM >>>> that's >>>> set up to use the requested version. You can then use the normal >>>> method/lambda invocation methods to run code in that JVM. >>>> >>>> Currently version "100" (1.0.0-incubating) is available for >>>> backward-compatibility testing. Versions to be tested are configured in >>>> geode-old-versions/build.gradle as source-sets. Adding a new version is >>>> trivial. >>>> >>>> >> >
