Speaking from experience (Reaper), I can say that developing a sidecar admin / repair tool out of tree that's compatible with multiple versions really isn't that big of a problem. We've been doing it for a while now.
https://github.com/thelastpickle/cassandra-reaper/blob/master/.travis.yml On Fri, Aug 17, 2018 at 9:39 AM Joseph Lynch <joe.e.ly...@gmail.com> wrote: > While I would love to use a different build system (e.g. gradle) for the > sidecar, I agree with Dinesh that a separate repo would make sidecar > development much harder to verify, especially on the testing and > compatibility front. As Jeremiah mentioned we can always choose later to > release the sidecar artifact separately or more frequently than the main > server regardless of repo choice and as per Roopa's point having a separate > release artifact (jar or deb/rpm) is probably a good idea until the default > Cassandra packages don't automatically stop and start Cassandra on install. > > While we were developing the repair scheduler in a separate repo we had a > number of annoying issues that only started surfacing once we started > merging it directly into the trunk tree: > 1. It is hard to compile/test against unreleased versions of Cassandra > (e.g. the JMX interfaces changed a lot with 4.x, and it was pretty tricky > to compile against that as the main project doesn't release nightly > snapshots or anything like that, so we had to build local trunk jars and > then manually dep them). > 2. Integration testing and cross version compatibility is extremely hard. > The sidecar is going to be involved in multi node coordination (e.g. > monitoring, metrics, maintenance) and will be tightly coupled to JMX > interface choices in the server and trying to make sure that it all works > with multiple versions of Cassandra is much harder if it's a separate repo > that has to have a mirroring release cycle to Cassandra. It seems much > easier to have it in tree and just be like "the in tree sidecar is tested > against that version of Cassandra". Every time we cut a Cassandra server > branch the sidecar branches with it. > > We experience these pains all the time with Priam being in a separate repo, > where every time we support a new Cassandra version a bunch of JMX > endpoints break and we have to refactor the code to either call JMX methods > by string or cut a new Priam branch. A separate artifact is pretty > important, but a separate repo just allows drifts. Furthermore from the > Priam experience I also don't think it's realistic to say one version of a > sidecar artifact can actually support multiple versions. > > -Joey > > On Fri, Aug 17, 2018 at 12:00 PM Jeremiah D Jordan <jerem...@datastax.com> > wrote: > > > Not sure why the two things being in the same repo means they need the > > same release process. You can always do interim releases of the > management > > artifact between server releases, or even have completely decoupled > > releases. > > > > -Jeremiah > > > > > On Aug 17, 2018, at 10:52 AM, Blake Eggleston <beggles...@apple.com> > > wrote: > > > > > > I'd be more in favor of making it a separate project, basically for all > > the reasons listed below. I'm assuming we'd want a management process to > > work across different versions, which will be more awkward if it's in > tree. > > Even if that's not the case, keeping it in a different repo at this point > > will make iteration easier than if it were in tree. I'd imagine (or at > > least hope) that validating the management process for release would be > > less difficult than the main project, so tying them to the Cassandra > > release cycle seems unnecessarily restrictive. > > > > > > > > > On August 17, 2018 at 12:07:18 AM, Dinesh Joshi ( > dinesh.jo...@yahoo.com.invalid) > > wrote: > > > > > >> On Aug 16, 2018, at 9:27 PM, Sankalp Kohli <kohlisank...@gmail.com> > > wrote: > > >> > > >> I am bumping this thread because patch has landed for this with repair > > functionality. > > >> > > >> I have a following proposal for this which I can put in the JIRA or > doc > > >> > > >> 1. We should see if we can keep this in a separate repo like Dtest. > > > > > > This would imply a looser coupling between the two. Keeping things > > in-tree is my preferred approach. It makes testing, dependency management > > and code sharing easier. > > > > > >> 2. It should have its own release process. > > > > > > This means now there would be two releases that need to be managed and > > coordinated. > > > > > >> 3. It should have integration tests for different versions of > Cassandra > > it will support. > > > > > > Given the lack of test infrastructure - this will be hard especially if > > you have to qualify a matrix of builds. > > > > > > Dinesh > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
