+1 for separate repo
-- Jeff Jirsa > On Aug 23, 2018, at 1:00 PM, sankalp kohli <kohlisank...@gmail.com> wrote: > > Separate repo is in a majority so far. Please reply to this thread with > your responses. > > On Tue, Aug 21, 2018 at 4:34 PM Rahul Singh <rahul.xavier.si...@gmail.com> > wrote: > >> +1 for separate repo. Especially on git. Maybe make it a submodule. >> >> Rahul >> On Aug 21, 2018, 3:33 PM -0500, Stefan Podkowinski <s...@apache.org>, >> wrote: >>> I'm also currently -1 on the in-tree option. >>> >>> Additionally to what Aleksey mentioned, I also don't see how we could >>> make this work with the current build and release process. Our scripts >>> [0] for creating releases (tarballs and native packages), would need >>> significant work to add support for an independent side-car. Our ant >>> based build process is also not a great start for adding new tasks, let >>> alone integrating other tool chains for web components for a potential >> UI. >>> >>> [0] https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git >>> >>> >>>> On 21.08.18 19:20, Aleksey Yeshchenko 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 >>>>> >>>>> >>> >>> >>> --------------------------------------------------------------------- >>> 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
