FWIW, I think it's possible to merge in a separate repository into a subdirectory while keeping git history, but I don't know if the other way will be possible if commits span other parts of the repo as well\* (which will likely happen sooner or later). So a separate repo is a choice we can backtrack from if it proves problematic later.
\* it may be possible, but the commit messages might not make much sense after that. On Fri, 24 Aug 2018, 09:12 Benedict Elliott Smith, <bened...@apache.org> wrote: > +1 also for separate repo > > > On 24 Aug 2018, at 01:11, Jeff Jirsa <jji...@gmail.com> wrote: > > > > +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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- Muru
