Cassandra 2.2 and/or 3.x

[hgfischer]

Hi,

Does this tool works with Cassandra 2.2 and/or 3.x?

thanks

[BackendButters]

Tried it with 3.3 but doesn't work. Seems like this is not maintained so much anymore. Bummer!

[brstgt]

Could someone from Spotify please comment if this project is still maintained?
Is there a reason, why there is no 3.x support, to me it seemed just a few lines. Doesn't spotify use 3.x?
There are a lot of forks out there that do more or less the same things: Fix version compatibility.
I got my fork up and running on 3.9, I can create a pull request if it is desirable

Wouldn't it also be viable to integrate the UI into this repo? It is a very usefull component and I see no reason why it should not be shipped together. Integrating the UI also would make the build simpler?

[mmatalka]

Hello, at the moment Spotify does not use 3.x. Updating reaper to support later versions of Cassandra is in our roadmap but dose not have a time planned, but most likely in Q4.

The primary reason all these PRs have not been merged in is because they break backwards compatibility with 2.0.x, which we still need for now. (or at least all of the PRs I've seen give up a version to get a version).

If there is a PR which supports all versions of Cassandra >= 2.0.x, that would be a good candidate for getting merged in and become master.

As for the UI, I do not have a strong opinion but keeping them in separate repos sounds like the right thing to do.

tl;dr - if there is a PR that gives support from 2.0 and onwards in a reasonable way, that has a good chance of getting merged.

[brstgt]

Thanks for your fast reply!

For my understanding the way to support multiple versions could look like this:

• Get the server version from JMX or use a configured value (probably bad idea, nodes can upgrade, multi-version cluster, ...)
• As it is not possible to link multiple versions of cassandra client due to namespacing conflicts, we could copy the MBean interfaces from the old client.
• Between spotify version and latest release only 2 places are affected: jmxProxy.getPendingCompactions and JmxProxy.triggerRepair which uses StorageServiceMBean
• There needs to be a switch when opening ssProxy to use latest MBean Interface vs "old interface"
• To get pending compactions there needs to be a switch to use the old CompactionManagerMBean vs. "org.apache.cassandra.metrics:name=PendingTasks,type=Compaction"

The short way would be just to use switches and or different proxy objects in JmxProxy.
The "good way" would maybe to create a JmxProxy factory with a JmxProxyInterface and 2 slightly different implementations using a common base implementation.

Agree?

[brstgt]

P.S.: I love spotify ❤️

[mmatalka]

There are a few options. One idea that we have an initial implementation for, but not done, is to actually move the JMX calls out to separate processes, one for each version of Cassandra. And then the reaper process has to know which one of these to communicate to.

Another idea is to move a repair process to each cassandra node and then the reaper process can ssh in or trigger this in some way, and that way the versioning is at the node it self and reaper doesn't care. This simplifies the reaper implementation.

[brstgt]

Moving out to many processes maybe simplifies the structure of that agents but makes the administration more complicated. The more workers there are the more workers can fail and probably will, so then there must be more monitoring and or supervision.
You move the "interface unification" from Java Interfaces to protocols (HTTP, JMX, whatever). You also will end up in a more complex build setup. Maybe you want to setup sub-projects to be able to deal with dependencies of multiple versions.

I am really new to cassandra and reaper so I don't have much experience with it but if you are happy with the current implementation for your needs I would first try to stay with it and try to handle things within a single process (least effort). If it turns out that this wont work (properly) then I'd try to "scale out". Just my 2 cents.