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
>
>
