[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Side Car New Repo vs not

An option is to create a mono repo with Cassandra and SideCar as modules that could be built independently. This would keep source for both artifacts in the same repo and have their own release cadences. That said, I don't have any strong opinions at this point. We can try going with a separate repo and reevaluate it if it doesn't work out.

    On Monday, August 20, 2018, 9:21:33 PM PDT, Blake Eggleston <beggleston@xxxxxxxxx> 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.lynch@xxxxxxxxx) 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  
* 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.  


On Mon, Aug 20, 2018 at 1:52 PM sankalp kohli <kohlisankalp@xxxxxxxxx>  

> 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