Sure, allow me to elaborate - at least a little bit. But before I do, just let me note that this wasn’t a veto -1, just a shorthand for “I don’t like this option”.
It would be nice to have sidecar and C* version and release cycles fully decoupled. I know it *can* be done when in-tree, but the way we vote on releases with tags off current branches would have to change somehow. Probably painfully. It would be nice to be able to easily enforce freezes, like the upcoming one, on the whole C* repo, while allowing feature development on the sidecar. It would be nice to not have sidecar commits in emails from commits@ mailing list. It would be nice to not have C* CI trigger necessarily on sidecar commits. Groups of people working on the two repos will mostly be different too, so what’s the point in sharing the repo? Having an extra repo with its own set of branches is cheap and easy - we already do that with dtests. I like cleanly separated things when coupling is avoidable. As such I would prefer the sidecar to live in a separate new repo, while still being part of the C* project. — AY On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank...@gmail.com) wrote: Hi Aleksey, Can you please elaborate on the reasons for your -1? This way we can make progress towards any one approach. Thanks, Sankalp On Tue, Aug 21, 2018 at 8:39 AM Aleksey Yeshchenko <alek...@apple.com> wrote: > FWIW I’m strongly -1 on in-tree approach, and would much prefer a separate > repo, dtest-style. > > — > AY > > On 21 August 2018 at 16:36:02, Jeremiah D Jordan ( > jeremiah.jor...@gmail.com) wrote: > > I think the following is a very big plus of it being in tree: > >> * 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, > > I also don’t see a reason why the sidecar being in tree means it would not > work in a mixed version cluster. The nodes themselves must work in a mixed > version cluster during a rolling upgrade, I would expect any management > side car to operate in the same manor, in tree or not. > > This tool will be pretty tightly coupled with the server, and as someone > with experience developing such tightly coupled tools, it is *much* easier > to make sure you don’t accidentally break them if they are in tree. How > many times has someone updated some JMX interface, updated nodetool, and > then moved on? Breaking all the external tools not in tree, without > realizing it. The above point about being able to modify interfaces and the > side car in the same commit is huge in terms of making sure someone doesn’t > inadvertently break the side car while fixing something else. > > -Jeremiah > > > > On Aug 21, 2018, at 10:28 AM, Jonathan Haddad <j...@jonhaddad.com> > wrote: > > > > 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
