Re: Rebuild through JMX

2018-08-21 Thread Cyril Scetbon
To follow up on that question, is there a way to know if the last long operation triggered through the JMX succeeded ? Still trying to find a way to answer the question without looking at logs. — Cyril Scetbon > On Aug 19, 2018, at 11:19 PM, Cyril Scetbon wrote: > > Hi, > > I want to trigger

Re: Proposing an Apache Cassandra Management process

2018-08-21 Thread Mick Semb Wever
> > contributions should be evaluated based on the merit of code and their > > value add to the whole offering. I hope it does not matter whether that > > contribution comes from PMC member or a person who is not a committer. > > > I hope this goes without saying. Absolutely. Joseph and

Re: Side Car New Repo vs not

2018-08-21 Thread Rahul Singh
+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

Re: Side Car New Repo vs not

2018-08-21 Thread Stefan Podkowinski
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

Re: Side Car New Repo vs not

2018-08-21 Thread Jason Brown
+1 for separate repo. For pretty much all the same reasons Aleksey elucidated. On Tue, Aug 21, 2018 at 10:20 AM, 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 >

Security question

2018-08-21 Thread Joseph Testa
Would anyone be interested in assisting me with writing the Center for Internet Security(CIS) benchmark for Cassandra? If so, shoot me an email i...@dbsec-it.com and let's chat. Thanks, Joe

Re: Side Car New Repo vs not

2018-08-21 Thread Aleksey Yeshchenko
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

Re: Side Car New Repo vs not

2018-08-21 Thread sankalp kohli
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 >

Re: Side Car New Repo vs not

2018-08-21 Thread Aleksey Yeshchenko
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

Re: Side Car New Repo vs not

2018-08-21 Thread Jeremiah D Jordan
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 >>

Re: Side Car New Repo vs not

2018-08-21 Thread Jonathan Haddad
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