+1 for a separate repo On Fri, 24 Aug 2018 at 06:40, Michael Shuler <mich...@pbandjelly.org> wrote:
> +1 for a separate repository. > > Michael > > On 08/23/2018 07:30 PM, Murukesh Mohanan wrote: > > 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
