Strongly agree with Blake. In my mind supporting multiple versions is mandatory. As I've stated before, we already do it with Reaper, I'd consider it a major misstep if we couldn't support multiple with the project - provided admin tool. It's the same reason dtests are separate - they work with multiple versions.
The number of repos does not affect distribution - if we want to ship Cassandra with the admin / repair tool (we should, imo), that can be part of the build process. On Mon, Aug 20, 2018 at 9:21 PM Blake Eggleston <beggles...@apple.com> wrote: > If the sidecar is going to be on a different release cadence, or support > interacting with mixed mode clusters, then it should definitely be in a > separate repo. I don’t even know how branching and merging would work in a > repo that supports 2 separate release targets and/or mixed mode > compatibility, but I’m pretty sure it would be a mess. > > As a cluster management tool, mixed mode is probably going to be a goal at > some point. As a new project, it will benefit from not being tied to the C* > release cycle (which would probably delay any sidecar release until > whenever 4.1 is cut). > > > On August 20, 2018 at 3:22:54 PM, Joseph Lynch (joe.e.ly...@gmail.com) > wrote: > > I think that the pros of incubating the sidecar in tree as a tool first > outweigh the alternatives at this point of time. Rough tradeoffs that I > see: > > Unique pros of in tree sidecar: > * Faster iteration speed in general. For example when we need to add a > new > JMX endpoint that the sidecar needs, or change something from JMX to a > virtual table (e.g. for repair, or monitoring) we can do all changes > including tests as one commit within the main repository and don't have > to > commit to main repo, sidecar repo, and dtest repo (juggling version > compatibility along the way). > * We can in the future more easily move serious background functionality > like compaction or repair itself (not repair scheduling, actual > repairing) > into the sidecar with a single atomic commit, we don't have to do two > phase > commits where we add some IPC mechanism to allow us to support it in > both, > then turn it on in the sidecar, then turn it off in the server, etc... > * I think that the verification is much easier (sounds like Jonathan > disagreed on the other thread, I could certainly be wrong), and we don't > have to worry about testing matrices to assure that the sidecar works > with > various versions as the version of the sidecar that is released with that > version of Cassandra is the only one we have to certify works. If people > want to pull in new versions or maintain backports they can do that at > their discretion/testing. > * We can iterate and prove value before committing to a choice. Since it > will be a separate artifact from the start we can always move the > artifact > to a separate repo later (but moving the other way is harder). > * Users will get the sidecar "for free" when they install the daemon, > they > don't need to take affirmative action to e.g. be able to restart their > cluster, run repair, or back their data up; it just comes out of the box > for free. > > Unique pros of a separate repository sidecar: > * We can use a more modern build system like gradle instead of ant > * Merging changes is less "scary" I guess (I feel like if you're not > touching the daemon this is already true but I could see this being less > worrisome for some). > * Releasing a separate artifact is somewhat easier from a separate repo > (especially if we have gradle which makes e.g. building debs and rpms > trivial). > * We could backport to previous versions without getting into arguments > about bug fixes vs features. > * Committers could be different from the main repo, which ... may be a > useful thing > > Non unique pros of a sidecar (could be achieved in the main repo or in a > separate repo): > * A separate build artifact .jar/.deb/.rpm that can be installed > separately. It's slightly easier with a separate repo but certainly not > out > of reach within a single repo (indeed the current patch already creates a > separate jar, and we could create a separate .deb reasonably easily). > Personally I think having a separate .deb/.rpm is premature at this point > (for companies that really want it they can build their own packages > using > the .jars), but I think it really is a distracting issue from where the > patch should go as we can always choose to remove experimental .jar files > that the main daemon doesn't touch. > * A separate process lifecycle. No matter where the sidecar goes, we get > the benefit of restarting it being less dangerous for availability than > restarting the main daemon. > > That all being said, these are strong opinions weakly held and I would > rather get something actually committed so that we can prove value one > way > or the other and am therefore, of course, happy to put sidecar patches > wherever someone can review and commit it. > > -Joey > > On Mon, Aug 20, 2018 at 1:52 PM sankalp kohli <kohlisank...@gmail.com> > wrote: > > > Hi, > > I am starting a new thread to get consensus on where the side car > > should be contributed. > > > > Please send your responses with pro/cons of each approach or any other > > approach. Please be clear which approach you will pick while still > giving > > pros/cons of both approaches. > > > > Thanks. > > Sankalp > > > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
