+1 for separate repo. For pretty much all the same reasons Aleksey elucidated.
On Tue, Aug 21, 2018 at 10:20 AM, Aleksey Yeshchenko <alek...@apple.com> wrote: > 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 > > > > >
