Dynamically download redis version according to specified version.

[thomasdarimont]

It would be very useful to be able to dynamically download the appropriate redis binaries according to a specified version. This would help with regression tests for instance - in Spring Data Redis - we often have to run tests with different versions of redis.

[kstyrc]

Pretty cool idea. Any suggestion how to include that in the API?

Couple of the things to note:

• Should the user specify full resource URI (ex. http://download.redis.io/releases/redis-2.8.19.tar.gz) or only version (ex. 2.8.19)?
• If only version, then how to enable API user to override base URI (ex. http://download.redis.io/releases) ?
• Should cache for redis binaries be used? If so, where to store it?

[kstyrc]

My first proposal We already have some RedisExecProvider concept (see #29). How about to make it an interface:

public interface RedisExecProvider {
  File get(OS os, Architecture arch);
}

where a couple of implementations are possible:

• DefaultRedisExecProvider - retrieves default redis binary from JAR
• CustomRedisExecProvider - retrieves redis binary from given location per os/arch
• DownloadRedisExecProvider - retrieves redis binary from given URLs with optional cache on-disk

Then, use such provider when constructing RedisServer:

RedisServer redisServer = RedisServer.builder()
  .redisExecProvider(customProvider)
  .port(6379)
  .slaveOf("locahost", 6378)
  .configFile("/path/to/your/redis.conf")
  .build();

[thomasdarimont]

Cool!

It would be helpful to be able to request a specific redis version for a test. Furthermore it would be useful to be able to use a ${REDIS_VERSION} placeholder in the config file path. Furthermore we often test redis in standalone, sentinel, cluster configuration. So it would be cool if there were a way to tag a configuration setting like: test this with "redis 2.8.19" with the "sentinel configuration" in "variant 42".

It would also great to be able to say ... test this with the "LATEST" redis version. This check could be done once per on test JVM bootstrap (if it detects a newer redis version, the new version is downloaded... next (jvm) start would use the new version.)

So I'd update your API like so:

public interface RedisExecutableProvider {
 File get(OS os, Architecture arch, RedisVersion version, String tag);
}

RedisVersionwould obviously encapsulate the Redis version string and could have additional metadata like c.f.: feature detection (supports sentinel?, supports cluster?, supports command?).

The tagString could be used as an arbitrary marker to tag different configurations or redis installations - should be available as a placeholder as well.

Another point would be to be able to start a bunch of redis servers (e.g. to test against a local cluster) on different ports (or just with different config-files) etc.

Perhaps an abstraction along the lines of a RedisInfrastructureBuilder could be useful:

interface RedisInfrastructureBuilder{
   RedisInfrastructure build(RedisInfrastructureSpecification spec);
}

interface RedisInfrastructureSpecification{
 //builders for potentially combinding multiple RedisServers etc.
}

interface RedisInfrastructure{
   Future<State> start();
   Future<State> stop();
}

enum State{STARTED, STOPPED}

[kstyrc]

Regarding RedisInfrastructureBuilder, doesn't RedisCluster address this?

See: Setting up a cluster

[varunmehta]

curious, are you pursuing this ticket ?