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
