Re: Roadmap for 4.0

[Jeff Beck]

If you are going to make 4 bigger as long as we call out that 3.11.x (or
whatever) will keep getting patches for stability only that's all that's
needed. We haven't gone to 3.x releases many places yet as we wait for a
release that will be stable longer. Knowing 4 is going to be bigger I
wouldn't want to see more feature releases in 3.x

I wouldn't want to greatly slow features down if they require a major
release and 5 is too far off.

Jeff

On Mon, Apr 9, 2018, 4:05 PM Josh McKenzie  wrote:

> >
> > If they're not close to finished now why even consider them for the 4.0
> > release?
>
> Merging in major features at the end of a release cycle is not the path to
> stability, imo.
>
> On Mon, Apr 9, 2018 at 4:56 PM, Jonathan Haddad  wrote:
>
> > There's always more stuff to try to shoehorn in.  We've done big releases
> > with all the things, it never was stable.  We tried the opposite end of
> the
> > spectrum, release every month, that really wasn't great either.
> Personally
> > I'd be OK with stopping new features by the end of this month and aiming
> to
> > release a stable 4.0 when we agree we would be comfortable dogfooding it
> in
> > production at our own companies (in a few months), and aim for 4.1 (or
> 5.0
> > I don't want to bikeshed the version) for pluggable storage and transient
> > replicas.  If they're not close to finished now why even consider them
> for
> > the 4.0 release?  They're so core they should be merged into trunk at the
> > beginning of the cycle for the follow up release in order to get as much
> > exposure as possible.
> >
> > Jon
> >
> > On Mon, Apr 9, 2018 at 1:46 PM Nate McCall  wrote:
> >
> > > > I'd like to see pluggable storage and transient replica tickets land,
> > for
> > > > starters.
> > >
> > > I think both those features are, frankly, necessary for our future. On
> > > the other hand, they both have the following risks:
> > > 1. core behavioral changes
> > > 2. require changing a (relatively) large surface area of code
> > >
> > > We can aim to de-risk 4.0 by focusing on what we have now which is
> > > solid repair and NIO internode (maybe we move the 4.0 branch timeline
> > > up?), aiming for a 4.1 following soon-ish.
> > >
> > > Or we can go in eyes open and agree on a larger footprint 4.0.
> > >
> > > I'm on the fence, tbh (can't emphasize enough how big both those
> > > features will be). I just want everyone to know what we are getting
> > > into and that we are potentially impacting our goals of "stable" ==
> > > "exciting."
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: Roadmap for 4.0

[Josh McKenzie]

>
> If they're not close to finished now why even consider them for the 4.0
> release?

Merging in major features at the end of a release cycle is not the path to
stability, imo.

On Mon, Apr 9, 2018 at 4:56 PM, Jonathan Haddad  wrote:

> There's always more stuff to try to shoehorn in.  We've done big releases
> with all the things, it never was stable.  We tried the opposite end of the
> spectrum, release every month, that really wasn't great either.  Personally
> I'd be OK with stopping new features by the end of this month and aiming to
> release a stable 4.0 when we agree we would be comfortable dogfooding it in
> production at our own companies (in a few months), and aim for 4.1 (or 5.0
> I don't want to bikeshed the version) for pluggable storage and transient
> replicas.  If they're not close to finished now why even consider them for
> the 4.0 release?  They're so core they should be merged into trunk at the
> beginning of the cycle for the follow up release in order to get as much
> exposure as possible.
>
> Jon
>
> On Mon, Apr 9, 2018 at 1:46 PM Nate McCall  wrote:
>
> > > I'd like to see pluggable storage and transient replica tickets land,
> for
> > > starters.
> >
> > I think both those features are, frankly, necessary for our future. On
> > the other hand, they both have the following risks:
> > 1. core behavioral changes
> > 2. require changing a (relatively) large surface area of code
> >
> > We can aim to de-risk 4.0 by focusing on what we have now which is
> > solid repair and NIO internode (maybe we move the 4.0 branch timeline
> > up?), aiming for a 4.1 following soon-ish.
> >
> > Or we can go in eyes open and agree on a larger footprint 4.0.
> >
> > I'm on the fence, tbh (can't emphasize enough how big both those
> > features will be). I just want everyone to know what we are getting
> > into and that we are potentially impacting our goals of "stable" ==
> > "exciting."
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Roadmap for 4.0

[J. D. Jordan]

Myself I would put my non-binding vote for the stable side. I think those are 
both important, but maybe they are best as some of the first things to go into 
“release after 4.0”, not the last things to go into 4.0.
Maybe they would also prove as some incentive to get the next release out the 
door a little quicker than 4.0 will end up being ;).

-Jeremiah

On Apr 9, 2018, at 4:46 PM, Nate McCall  wrote:

>> I'd like to see pluggable storage and transient replica tickets land, for
>> starters.
> 
> I think both those features are, frankly, necessary for our future. On
> the other hand, they both have the following risks:
> 1. core behavioral changes
> 2. require changing a (relatively) large surface area of code
> 
> We can aim to de-risk 4.0 by focusing on what we have now which is
> solid repair and NIO internode (maybe we move the 4.0 branch timeline
> up?), aiming for a 4.1 following soon-ish.
> 
> Or we can go in eyes open and agree on a larger footprint 4.0.
> 
> I'm on the fence, tbh (can't emphasize enough how big both those
> features will be). I just want everyone to know what we are getting
> into and that we are potentially impacting our goals of "stable" ==
> "exciting."
> 
> -
> 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

Re: Roadmap for 4.0

[Nate McCall]

> I'd like to see pluggable storage and transient replica tickets land, for
> starters.

I think both those features are, frankly, necessary for our future. On
the other hand, they both have the following risks:
1. core behavioral changes
2. require changing a (relatively) large surface area of code

We can aim to de-risk 4.0 by focusing on what we have now which is
solid repair and NIO internode (maybe we move the 4.0 branch timeline
up?), aiming for a 4.1 following soon-ish.

Or we can go in eyes open and agree on a larger footprint 4.0.

I'm on the fence, tbh (can't emphasize enough how big both those
features will be). I just want everyone to know what we are getting
into and that we are potentially impacting our goals of "stable" ==
"exciting."

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Roadmap for 4.0

[Jeff Jirsa]

I'd like to see pluggable storage and transient replica tickets land, for
starters.

On Mon, Apr 9, 2018 at 10:17 AM, Ben Bromhead  wrote:

> >
> > For those wanting to delay, are we just dancing around inclusion of
> > some pet features? This is fine, I just think we need to communicate
> > what we are after if so.
> >
>
> +1 Some solid examples of tickets that won't make it with the proposed
> timeline and a proposed alternative would help.
>
> Otherwise if no one chimes in I would propose sticking with June 1.
>
>
>
>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
>

Re: Roadmap for 4.0

[Ben Bromhead]

>
> For those wanting to delay, are we just dancing around inclusion of
> some pet features? This is fine, I just think we need to communicate
> what we are after if so.
>

+1 Some solid examples of tickets that won't make it with the proposed
timeline and a proposed alternative would help.

Otherwise if no one chimes in I would propose sticking with June 1.




>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> --
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer

Re: CommitLogSegmentManager verbose debug log

[Nicolas Guyomar]

Always interested in helping ! I submitted 2 small patches on 3.11 and trunk

Thank you

On 8 April 2018 at 01:34, Jay Zhuang  wrote:

>  Make senses to me. Not sure if I should just push a Ninja fix, created
> the ticket anyway: CASSANDRA-14370. Are you interested in creating a quick
> patch for it?
> On Tuesday, April 3, 2018, 3:06:28 AM PDT, Nicolas Guyomar <
> nicolas.guyo...@gmail.com> wrote:
>
>  Hi Jay,
>
> Well the log in itself does not provide useful information (like segment
> number or sthg like that), so IMHO trace would be a better level for this
> one
>
> I agree that one log per sec may not be seen that verbose !
>
> Thank you
>
> On 30 March 2018 at 06:36, Jay Zhuang  wrote:
>
> > It's changed to trace() in cassandra-3.0 with CASSANDRA-10241:
> > https://github.com/pauloricardomg/cassandra/commit/
> > 3ef1b18fa76dce7cd65b73977fc30e51301f3fed#diff-
> > d07279710c482983e537aed26df80400
> >
> > In cassandra-3.11 (and trunk), it's changed back to debug() with
> > CASSANDRA-10202:
> > https://github.com/apache/cassandra/commit/
> e8907c16abcd84021a39cdaac79b60
> > 9fcc64a43c#diff-85e13493c70723764c539dd222455979
> >
> > The message is logged when a new commit-log is created, so it's not that
> > verbose from my point of view. But I'm also fine to change it back to
> trace.
> >
> > Here is a sample of debug.log while running cassandra-stress:
> > https://gist.githubusercontent.com/cooldoger/
> > 12f507da9b41b232d8869bbcd2bfd02b/raw/241cd8f0639269966aa53e2b10cee6
> > 13f8ed8cfe/gistfile1.txt
> >
> >
> >
> > On Thursday, March 29, 2018, 8:47:54 AM PDT, Nicolas Guyomar <
> > nicolas.guyo...@gmail.com> wrote:
> >
> >
> > Hi guys,
> >
> > I'm trying to understand the meaning of the following log
> > in org.apache.cassandra.db.commitlog.CommitLogSegmentManager.java
> >
> > logger.debug("No segments in reserve; creating a fresh one");
> >
> > I feel like it could be remove, as it seems to be kind of a continuous
> task
> > of providing segment
> >
> > Any thought on removing this log ? (my debug.log is quite full of it)
> >
> > Thank you
> >
> > Nicolas
> >
>
>