Re: Supporting multiple JDKs
> > There's a cost-optimisation here in reducing what we have to support. > > I agree and animal sniffer is a great way to ferret out obvious issues. > I am not against using animal sniffer. I'm concerned that there are > various incompatibilities[1] between JDK versions and I am not 100% > certain that animal sniffer will catch all of them. Yeah, but is compiling (and unit tests) really any more effective against behavioural incompatibilities (which also occur from one patch JDK version to the next)? I think that dtests are always going to be the important defence here, and that we simplify it by running dtests on a standardised JDK compile. regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Side Car New Repo vs not
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 wrote: > +1 for separate repo. Especially on git. Maybe make it a submodule. > > Rahul > On Aug 21, 2018, 3:33 PM -0500, Stefan Podkowinski , > 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 > > > 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 > > > > 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 < >
Re: Supporting multiple JDKs
I am not against using a compile-time quick-feedback tool like Animal Sniffer either. It is great to have such a tool to know of any obvious bad changes right away during development. However, in addition to using such a tool, I believe, when we make a release, we should build against the actual JDKs we support (that way, we are not making a release just based on the result of an external tool), and we should be able to optionally run UTs and DTests against the JDK (i.e. Java7 and Java8 for C* 2.2). > What do we mean "support multiple JDKs" ? > Are we talking Run-time or Compile-time? I am talking both - compile-time can for Build, run-time for UTs and DTests. > I think that dtests are always going to be the important defence here, and that we simplify it by running dtests on a standardised JDK compile. I agree, but its good to have an optional workflow in CircleCI to be able to run DTest against the non-standardized JDK as well, which we support (Java7 for example, for C*2.2, and Java11 for C* 4.0) Thanks, Sumanth On Thu, Aug 23, 2018 at 12:06 AM Mick Semb Wever wrote: > > > > There's a cost-optimisation here in reducing what we have to support. > > > > I agree and animal sniffer is a great way to ferret out obvious issues. > > I am not against using animal sniffer. I'm concerned that there are > > various incompatibilities[1] between JDK versions and I am not 100% > > certain that animal sniffer will catch all of them. > > > Yeah, but is compiling (and unit tests) really any more effective against > behavioural incompatibilities (which also occur from one patch JDK version > to the next)? > > I think that dtests are always going to be the important defence here, and > that we simplify it by running dtests on a standardised JDK compile. > > regards, > Mick > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Supporting multiple JDKs
Some of our java8 code will not compile under java11 (see CASSANDRA-9608); the symbols have literally been removed (Unsafe.monitorEnter() / Unsafe.monitorExit() ). Setting -source to "8" will not help. Thus, we need two compilers for the foreseeable future. On Thu, Aug 23, 2018 at 3:44 PM, Sumanth Pasupuleti < sumanth.pasupuleti...@gmail.com> wrote: > I am not against using a compile-time quick-feedback tool like Animal > Sniffer either. It is great to have such a tool to know of any obvious bad > changes right away during development. However, in addition to using such a > tool, I believe, when we make a release, we should build against the actual > JDKs we support (that way, we are not making a release just based on the > result of an external tool), and we should be able to optionally run UTs > and DTests against the JDK (i.e. Java7 and Java8 for C* 2.2). > > > What do we mean "support multiple JDKs" ? > > Are we talking Run-time or Compile-time? > I am talking both - compile-time can for Build, run-time for UTs and > DTests. > > > I think that dtests are always going to be the important defence here, > and that we simplify it by running dtests on a standardised JDK compile. > I agree, but its good to have an optional workflow in CircleCI to be able > to run DTest against the non-standardized JDK as well, which we support > (Java7 for example, for C*2.2, and Java11 for C* 4.0) > > Thanks, > Sumanth > > On Thu, Aug 23, 2018 at 12:06 AM Mick Semb Wever wrote: > > > > > > > There's a cost-optimisation here in reducing what we have to support. > > > > > > I agree and animal sniffer is a great way to ferret out obvious issues. > > > I am not against using animal sniffer. I'm concerned that there are > > > various incompatibilities[1] between JDK versions and I am not 100% > > > certain that animal sniffer will catch all of them. > > > > > > Yeah, but is compiling (and unit tests) really any more effective against > > behavioural incompatibilities (which also occur from one patch JDK > version > > to the next)? > > > > I think that dtests are always going to be the important defence here, > and > > that we simplify it by running dtests on a standardised JDK compile. > > > > regards, > > Mick > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: Side Car New Repo vs not
+1 for separate repo -- Jeff Jirsa > On Aug 23, 2018, at 1:00 PM, sankalp kohli 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 > wrote: > >> +1 for separate repo. Especially on git. Maybe make it a submodule. >> >> Rahul >> On Aug 21, 2018, 3:33 PM -0500, Stefan Podkowinski , >> 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 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 > 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
Re: Side Car New Repo vs not
+1 also for separate repo > On 24 Aug 2018, at 01:11, Jeff Jirsa wrote: > > +1 for separate repo > > > -- > Jeff Jirsa > > >> On Aug 23, 2018, at 1:00 PM, sankalp kohli 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 >> wrote: >> >>> +1 for separate repo. Especially on git. Maybe make it a submodule. >>> >>> Rahul >>> On Aug 21, 2018, 3:33 PM -0500, Stefan Podkowinski , >>> 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 > 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 >> 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
Re: Side Car New Repo vs not
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, wrote: > +1 also for separate repo > > > On 24 Aug 2018, at 01:11, Jeff Jirsa wrote: > > > > +1 for separate repo > > > > > > -- > > Jeff Jirsa > > > > > >> On Aug 23, 2018, at 1:00 PM, sankalp kohli > 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 , > >>> 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
Re: Supporting multiple JDKs
> However, in addition to using such a > tool, I believe, when we make a release, we should build against the actual > JDKs we support (that way, we are not making a release just based on the > result of an external tool), and we should be able to optionally run UTs > and DTests against the JDK (i.e. Java7 and Java8 for C* 2.2). I'm still a bit confused as to what's the benefit in compiling with jdk1.7 and then testing with jdk1.7 or jdk1.8 If you find breakages here that otherwise don't exist when it's compiled with jdk1.8 then that's just false-positives. As well as generally wasting CI resources. Either way, there's not much point discussing this as Cassandra-2.1 is about EOL, and Cassandra-4.0 is stuck with a very specific compile. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Side Car New Repo vs not
+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, > wrote: > >> +1 also for separate repo >> >>> On 24 Aug 2018, at 01:11, Jeff Jirsa wrote: >>> >>> +1 for separate repo >>> >>> >>> -- >>> Jeff Jirsa >>> >>> On Aug 23, 2018, at 1:00 PM, sankalp kohli >> 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 , > 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, >>>
