Re: Warn about SASI usage and allow to disable them

2019-01-26 Thread Sankalp Kohli
Can we have a page or a JIRA label which users can see to know why it is 
experimental. Putting a warning without telling why is not good. But since 
warning is better than nothing, I am -0 on warn

> On Jan 26, 2019, at 9:37 AM, Andrés de la Peña  
> wrote:
> 
> I agree with Paulo's proposal. I think it will give us a very desirable
> homogeneity in how we deal with experimental features.
> 
> I'm +1 to warning, config property, and experimental features (SASI and MV)
> disabled by default in trunk.
> 
> These are the explicit votes for now, if I'm counting right:
> 
> - CQL native protocol warning on create SASI index: three +1s, one +0 and
> two -0s
> - Config property to disable new SASI creation: ten +1s
> - New SASI creation disabled by default in trunk: nine +1s and one -0
> - New MV creation disabled by default in trunk: three +1s
> 
> If there are no objections, I'll update the patch by the end of next week.
> 
>> On Mon, 21 Jan 2019 at 19:26, Paulo Motta  wrote:
>> 
>> +1 to enable_sasi_indexes flag
>> +1 to disabling experimental features by default on 4.0 (SASI and MVs,
>> transient replication already disabled)
>> 
>> Regarding the warning on creation of SASI indexes, I think that's a
>> user-level warning complimentary to the flag, which is targeted to admins,
>> so +1. If people are bothered by this, we could add another flag to disable
>> warnings on experimental features, which would be applied to both this and
>> MV creation warning (and any other future experimental feature).
>> 
>> I think the warning should be "SASI indexes are experimental and are not
>> recommended for production use.", similar to the MV warning added on
>> CASSANDRA-13959.
>> 
>> We should open a doc ticket to list limitations of experimental features
>> (MVs, SASI, transient replication), but this should probably be out of the
>> scope of CASSANDRA-14866. Once we have this doc, we can maybe amend the
>> warning to include a link to the doc.
>> 
>> Now that the number of experimental feature flags is growing we should
>> perhaps unify all flags in a "experimental features" section on
>> cassandra.yaml to allow easily locating them - and a pointer to the
>> limitations doc once we have it.
>> 
>> Em qua, 16 de jan de 2019 às 20:18, sankalp kohli 
>> escreveu:
>> 
>>> If we want to put a warning, we should list in a doc all the open issues
>> it
>>> has along with explanation of how it can impact. We have a few in the
>> first
>>> email of this thread but we should put it in a doc for people to know
>> what
>>> are the issues and if they want to take that risk.
>>> 
>>> 
>>> 
>>> On Wed, Jan 16, 2019 at 3:14 PM Brandon Williams 
>> wrote:
>>> 
 Which, if I'm not mistaken, is the goal here?
 
> On Wed, Jan 16, 2019 at 5:12 PM Jeff Jirsa  wrote:
> 
> The cost is in how many users you scare away
> 
> --
> Jeff Jirsa
> 
> 
>> On Jan 16, 2019, at 2:34 PM, Brandon Williams 
 wrote:
>> 
>> Also it costs us nothing to add it.
>> 
>>> On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad <
>> j...@jonhaddad.com>
> wrote:
>>> 
>>> I'm +1 on the warning for two reasons.
>>> 
 A cqlsh warning only applies to those that create the sasi via
>>> cqlsh.
>>> 
>>> 1. When people are creating their schemas in development, this is
> usually
>>> the first step.  You use the REPL to figure out what you need,
>> then
 you
>>> copy your schema somewhere else.  The warning here should prevent
>> a
 lot
> of
>>> folks from making a serious mistake.
>>> 
>>> 2. It's consistent with how we warn when people try to use
 materialized
>>> views.
>>> 
>>> 
>>> 
>>> 
 On Wed, Jan 16, 2019 at 2:15 PM Mick Semb Wever 
> wrote:
 
 Regarding the warning, we might add it at least in 3.11, since
>> for
 that
 version the property to enable SASI is going to be present but
>> not
>>> disabled
 by default. WDYT?
 
 
 I'm  -0 on this.
 
 A single line warning in the logs on the sasi creation won't be
 noticed
>>> by
 many users.
 A cqlsh warning only applies to those that create the sasi via
>>> cqlsh.
 And we're not talking about patching client drivers to generate a
> warning
 there.
 
 So I'd be happy with a yaml comment on the config flag explaining
 that
 it's a beta feature and that users should check open tickets and
>>> understand
 current limitations on sasi before using them.
 
 regards,
 Mick
 
 
>>> -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
 
>>> 
>>> --
>>> Jon Haddad
>>> 

Re: Warn about SASI usage and allow to disable them

2019-01-26 Thread Andrés de la Peña
I agree with Paulo's proposal. I think it will give us a very desirable
homogeneity in how we deal with experimental features.

I'm +1 to warning, config property, and experimental features (SASI and MV)
disabled by default in trunk.

These are the explicit votes for now, if I'm counting right:

- CQL native protocol warning on create SASI index: three +1s, one +0 and
two -0s
- Config property to disable new SASI creation: ten +1s
- New SASI creation disabled by default in trunk: nine +1s and one -0
- New MV creation disabled by default in trunk: three +1s

If there are no objections, I'll update the patch by the end of next week.

On Mon, 21 Jan 2019 at 19:26, Paulo Motta  wrote:

> +1 to enable_sasi_indexes flag
> +1 to disabling experimental features by default on 4.0 (SASI and MVs,
> transient replication already disabled)
>
> Regarding the warning on creation of SASI indexes, I think that's a
> user-level warning complimentary to the flag, which is targeted to admins,
> so +1. If people are bothered by this, we could add another flag to disable
> warnings on experimental features, which would be applied to both this and
> MV creation warning (and any other future experimental feature).
>
> I think the warning should be "SASI indexes are experimental and are not
> recommended for production use.", similar to the MV warning added on
> CASSANDRA-13959.
>
> We should open a doc ticket to list limitations of experimental features
> (MVs, SASI, transient replication), but this should probably be out of the
> scope of CASSANDRA-14866. Once we have this doc, we can maybe amend the
> warning to include a link to the doc.
>
> Now that the number of experimental feature flags is growing we should
> perhaps unify all flags in a "experimental features" section on
> cassandra.yaml to allow easily locating them - and a pointer to the
> limitations doc once we have it.
>
> Em qua, 16 de jan de 2019 às 20:18, sankalp kohli 
> escreveu:
>
> > If we want to put a warning, we should list in a doc all the open issues
> it
> > has along with explanation of how it can impact. We have a few in the
> first
> > email of this thread but we should put it in a doc for people to know
> what
> > are the issues and if they want to take that risk.
> >
> >
> >
> > On Wed, Jan 16, 2019 at 3:14 PM Brandon Williams 
> wrote:
> >
> > > Which, if I'm not mistaken, is the goal here?
> > >
> > > On Wed, Jan 16, 2019 at 5:12 PM Jeff Jirsa  wrote:
> > >
> > > > The cost is in how many users you scare away
> > > >
> > > > --
> > > > Jeff Jirsa
> > > >
> > > >
> > > > > On Jan 16, 2019, at 2:34 PM, Brandon Williams 
> > > wrote:
> > > > >
> > > > > Also it costs us nothing to add it.
> > > > >
> > > > >> On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad <
> j...@jonhaddad.com>
> > > > wrote:
> > > > >>
> > > > >> I'm +1 on the warning for two reasons.
> > > > >>
> > > > >>> A cqlsh warning only applies to those that create the sasi via
> > cqlsh.
> > > > >>
> > > > >> 1. When people are creating their schemas in development, this is
> > > > usually
> > > > >> the first step.  You use the REPL to figure out what you need,
> then
> > > you
> > > > >> copy your schema somewhere else.  The warning here should prevent
> a
> > > lot
> > > > of
> > > > >> folks from making a serious mistake.
> > > > >>
> > > > >> 2. It's consistent with how we warn when people try to use
> > > materialized
> > > > >> views.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>> On Wed, Jan 16, 2019 at 2:15 PM Mick Semb Wever 
> > > > wrote:
> > > > >>>
> > > > >>> Regarding the warning, we might add it at least in 3.11, since
> for
> > > that
> > > > >>> version the property to enable SASI is going to be present but
> not
> > > > >> disabled
> > > > >>> by default. WDYT?
> > > > >>>
> > > > >>>
> > > > >>> I'm  -0 on this.
> > > > >>>
> > > > >>> A single line warning in the logs on the sasi creation won't be
> > > noticed
> > > > >> by
> > > > >>> many users.
> > > > >>> A cqlsh warning only applies to those that create the sasi via
> > cqlsh.
> > > > >>> And we're not talking about patching client drivers to generate a
> > > > warning
> > > > >>> there.
> > > > >>>
> > > > >>> So I'd be happy with a yaml comment on the config flag explaining
> > > that
> > > > >>> it's a beta feature and that users should check open tickets and
> > > > >> understand
> > > > >>> current limitations on sasi before using them.
> > > > >>>
> > > > >>> regards,
> > > > >>> Mick
> > > > >>>
> > > > >>>
> > -
> > > > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >>>
> > > > >>>
> > > > >>
> > > > >> --
> > > > >> Jon Haddad
> > > > >> http://www.rustyrazorblade.com
> > > > >> twitter: rustyrazorblade
> > > > >>
> > > >
> > > > -
> > > > To unsubscribe, 

Re: Warn about SASI usage and allow to disable them

2019-01-21 Thread Paulo Motta
+1 to enable_sasi_indexes flag
+1 to disabling experimental features by default on 4.0 (SASI and MVs,
transient replication already disabled)

Regarding the warning on creation of SASI indexes, I think that's a
user-level warning complimentary to the flag, which is targeted to admins,
so +1. If people are bothered by this, we could add another flag to disable
warnings on experimental features, which would be applied to both this and
MV creation warning (and any other future experimental feature).

I think the warning should be "SASI indexes are experimental and are not
recommended for production use.", similar to the MV warning added on
CASSANDRA-13959.

We should open a doc ticket to list limitations of experimental features
(MVs, SASI, transient replication), but this should probably be out of the
scope of CASSANDRA-14866. Once we have this doc, we can maybe amend the
warning to include a link to the doc.

Now that the number of experimental feature flags is growing we should
perhaps unify all flags in a "experimental features" section on
cassandra.yaml to allow easily locating them - and a pointer to the
limitations doc once we have it.

Em qua, 16 de jan de 2019 às 20:18, sankalp kohli 
escreveu:

> If we want to put a warning, we should list in a doc all the open issues it
> has along with explanation of how it can impact. We have a few in the first
> email of this thread but we should put it in a doc for people to know what
> are the issues and if they want to take that risk.
>
>
>
> On Wed, Jan 16, 2019 at 3:14 PM Brandon Williams  wrote:
>
> > Which, if I'm not mistaken, is the goal here?
> >
> > On Wed, Jan 16, 2019 at 5:12 PM Jeff Jirsa  wrote:
> >
> > > The cost is in how many users you scare away
> > >
> > > --
> > > Jeff Jirsa
> > >
> > >
> > > > On Jan 16, 2019, at 2:34 PM, Brandon Williams 
> > wrote:
> > > >
> > > > Also it costs us nothing to add it.
> > > >
> > > >> On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad 
> > > wrote:
> > > >>
> > > >> I'm +1 on the warning for two reasons.
> > > >>
> > > >>> A cqlsh warning only applies to those that create the sasi via
> cqlsh.
> > > >>
> > > >> 1. When people are creating their schemas in development, this is
> > > usually
> > > >> the first step.  You use the REPL to figure out what you need, then
> > you
> > > >> copy your schema somewhere else.  The warning here should prevent a
> > lot
> > > of
> > > >> folks from making a serious mistake.
> > > >>
> > > >> 2. It's consistent with how we warn when people try to use
> > materialized
> > > >> views.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> On Wed, Jan 16, 2019 at 2:15 PM Mick Semb Wever 
> > > wrote:
> > > >>>
> > > >>> Regarding the warning, we might add it at least in 3.11, since for
> > that
> > > >>> version the property to enable SASI is going to be present but not
> > > >> disabled
> > > >>> by default. WDYT?
> > > >>>
> > > >>>
> > > >>> I'm  -0 on this.
> > > >>>
> > > >>> A single line warning in the logs on the sasi creation won't be
> > noticed
> > > >> by
> > > >>> many users.
> > > >>> A cqlsh warning only applies to those that create the sasi via
> cqlsh.
> > > >>> And we're not talking about patching client drivers to generate a
> > > warning
> > > >>> there.
> > > >>>
> > > >>> So I'd be happy with a yaml comment on the config flag explaining
> > that
> > > >>> it's a beta feature and that users should check open tickets and
> > > >> understand
> > > >>> current limitations on sasi before using them.
> > > >>>
> > > >>> regards,
> > > >>> Mick
> > > >>>
> > > >>>
> -
> > > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >>>
> > > >>>
> > > >>
> > > >> --
> > > >> 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
> > >
> > >
> >
>


Re: Warn about SASI usage and allow to disable them

2019-01-16 Thread sankalp kohli
If we want to put a warning, we should list in a doc all the open issues it
has along with explanation of how it can impact. We have a few in the first
email of this thread but we should put it in a doc for people to know what
are the issues and if they want to take that risk.



On Wed, Jan 16, 2019 at 3:14 PM Brandon Williams  wrote:

> Which, if I'm not mistaken, is the goal here?
>
> On Wed, Jan 16, 2019 at 5:12 PM Jeff Jirsa  wrote:
>
> > The cost is in how many users you scare away
> >
> > --
> > Jeff Jirsa
> >
> >
> > > On Jan 16, 2019, at 2:34 PM, Brandon Williams 
> wrote:
> > >
> > > Also it costs us nothing to add it.
> > >
> > >> On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad 
> > wrote:
> > >>
> > >> I'm +1 on the warning for two reasons.
> > >>
> > >>> A cqlsh warning only applies to those that create the sasi via cqlsh.
> > >>
> > >> 1. When people are creating their schemas in development, this is
> > usually
> > >> the first step.  You use the REPL to figure out what you need, then
> you
> > >> copy your schema somewhere else.  The warning here should prevent a
> lot
> > of
> > >> folks from making a serious mistake.
> > >>
> > >> 2. It's consistent with how we warn when people try to use
> materialized
> > >> views.
> > >>
> > >>
> > >>
> > >>
> > >>> On Wed, Jan 16, 2019 at 2:15 PM Mick Semb Wever 
> > wrote:
> > >>>
> > >>> Regarding the warning, we might add it at least in 3.11, since for
> that
> > >>> version the property to enable SASI is going to be present but not
> > >> disabled
> > >>> by default. WDYT?
> > >>>
> > >>>
> > >>> I'm  -0 on this.
> > >>>
> > >>> A single line warning in the logs on the sasi creation won't be
> noticed
> > >> by
> > >>> many users.
> > >>> A cqlsh warning only applies to those that create the sasi via cqlsh.
> > >>> And we're not talking about patching client drivers to generate a
> > warning
> > >>> there.
> > >>>
> > >>> So I'd be happy with a yaml comment on the config flag explaining
> that
> > >>> it's a beta feature and that users should check open tickets and
> > >> understand
> > >>> current limitations on sasi before using them.
> > >>>
> > >>> regards,
> > >>> Mick
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>>
> > >>>
> > >>
> > >> --
> > >> 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
> >
> >
>


Re: Warn about SASI usage and allow to disable them

2019-01-16 Thread Brandon Williams
Which, if I'm not mistaken, is the goal here?

On Wed, Jan 16, 2019 at 5:12 PM Jeff Jirsa  wrote:

> The cost is in how many users you scare away
>
> --
> Jeff Jirsa
>
>
> > On Jan 16, 2019, at 2:34 PM, Brandon Williams  wrote:
> >
> > Also it costs us nothing to add it.
> >
> >> On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad 
> wrote:
> >>
> >> I'm +1 on the warning for two reasons.
> >>
> >>> A cqlsh warning only applies to those that create the sasi via cqlsh.
> >>
> >> 1. When people are creating their schemas in development, this is
> usually
> >> the first step.  You use the REPL to figure out what you need, then you
> >> copy your schema somewhere else.  The warning here should prevent a lot
> of
> >> folks from making a serious mistake.
> >>
> >> 2. It's consistent with how we warn when people try to use materialized
> >> views.
> >>
> >>
> >>
> >>
> >>> On Wed, Jan 16, 2019 at 2:15 PM Mick Semb Wever 
> wrote:
> >>>
> >>> Regarding the warning, we might add it at least in 3.11, since for that
> >>> version the property to enable SASI is going to be present but not
> >> disabled
> >>> by default. WDYT?
> >>>
> >>>
> >>> I'm  -0 on this.
> >>>
> >>> A single line warning in the logs on the sasi creation won't be noticed
> >> by
> >>> many users.
> >>> A cqlsh warning only applies to those that create the sasi via cqlsh.
> >>> And we're not talking about patching client drivers to generate a
> warning
> >>> there.
> >>>
> >>> So I'd be happy with a yaml comment on the config flag explaining that
> >>> it's a beta feature and that users should check open tickets and
> >> understand
> >>> current limitations on sasi before using them.
> >>>
> >>> regards,
> >>> Mick
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>>
> >>
> >> --
> >> 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
>
>


Re: Warn about SASI usage and allow to disable them

2019-01-16 Thread Jeff Jirsa
The cost is in how many users you scare away 

-- 
Jeff Jirsa


> On Jan 16, 2019, at 2:34 PM, Brandon Williams  wrote:
> 
> Also it costs us nothing to add it.
> 
>> On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad  wrote:
>> 
>> I'm +1 on the warning for two reasons.
>> 
>>> A cqlsh warning only applies to those that create the sasi via cqlsh.
>> 
>> 1. When people are creating their schemas in development, this is usually
>> the first step.  You use the REPL to figure out what you need, then you
>> copy your schema somewhere else.  The warning here should prevent a lot of
>> folks from making a serious mistake.
>> 
>> 2. It's consistent with how we warn when people try to use materialized
>> views.
>> 
>> 
>> 
>> 
>>> On Wed, Jan 16, 2019 at 2:15 PM Mick Semb Wever  wrote:
>>> 
>>> Regarding the warning, we might add it at least in 3.11, since for that
>>> version the property to enable SASI is going to be present but not
>> disabled
>>> by default. WDYT?
>>> 
>>> 
>>> I'm  -0 on this.
>>> 
>>> A single line warning in the logs on the sasi creation won't be noticed
>> by
>>> many users.
>>> A cqlsh warning only applies to those that create the sasi via cqlsh.
>>> And we're not talking about patching client drivers to generate a warning
>>> there.
>>> 
>>> So I'd be happy with a yaml comment on the config flag explaining that
>>> it's a beta feature and that users should check open tickets and
>> understand
>>> current limitations on sasi before using them.
>>> 
>>> regards,
>>> Mick
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 
>> --
>> 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



Re: Warn about SASI usage and allow to disable them

2019-01-16 Thread Brandon Williams
Also it costs us nothing to add it.

On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad  wrote:

> I'm +1 on the warning for two reasons.
>
> > A cqlsh warning only applies to those that create the sasi via cqlsh.
>
> 1. When people are creating their schemas in development, this is usually
> the first step.  You use the REPL to figure out what you need, then you
> copy your schema somewhere else.  The warning here should prevent a lot of
> folks from making a serious mistake.
>
> 2. It's consistent with how we warn when people try to use materialized
> views.
>
>
>
>
> On Wed, Jan 16, 2019 at 2:15 PM Mick Semb Wever  wrote:
>
> > Regarding the warning, we might add it at least in 3.11, since for that
> > version the property to enable SASI is going to be present but not
> disabled
> > by default. WDYT?
> >
> >
> > I'm  -0 on this.
> >
> > A single line warning in the logs on the sasi creation won't be noticed
> by
> > many users.
> > A cqlsh warning only applies to those that create the sasi via cqlsh.
> > And we're not talking about patching client drivers to generate a warning
> > there.
> >
> > So I'd be happy with a yaml comment on the config flag explaining that
> > it's a beta feature and that users should check open tickets and
> understand
> > current limitations on sasi before using them.
> >
> > regards,
> > Mick
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>


Re: Warn about SASI usage and allow to disable them

2019-01-16 Thread Jonathan Haddad
I'm +1 on the warning for two reasons.

> A cqlsh warning only applies to those that create the sasi via cqlsh.

1. When people are creating their schemas in development, this is usually
the first step.  You use the REPL to figure out what you need, then you
copy your schema somewhere else.  The warning here should prevent a lot of
folks from making a serious mistake.

2. It's consistent with how we warn when people try to use materialized
views.




On Wed, Jan 16, 2019 at 2:15 PM Mick Semb Wever  wrote:

> Regarding the warning, we might add it at least in 3.11, since for that
> version the property to enable SASI is going to be present but not disabled
> by default. WDYT?
>
>
> I'm  -0 on this.
>
> A single line warning in the logs on the sasi creation won't be noticed by
> many users.
> A cqlsh warning only applies to those that create the sasi via cqlsh.
> And we're not talking about patching client drivers to generate a warning
> there.
>
> So I'd be happy with a yaml comment on the config flag explaining that
> it's a beta feature and that users should check open tickets and understand
> current limitations on sasi before using them.
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade


Re: Warn about SASI usage and allow to disable them

2019-01-16 Thread Mick Semb Wever
Regarding the warning, we might add it at least in 3.11, since for that
version the property to enable SASI is going to be present but not disabled
by default. WDYT? 


I'm  -0 on this.

A single line warning in the logs on the sasi creation won't be noticed by many 
users.
A cqlsh warning only applies to those that create the sasi via cqlsh.
And we're not talking about patching client drivers to generate a warning there.

So I'd be happy with a yaml comment on the config flag explaining that it's a 
beta feature and that users should check open tickets and understand current 
limitations on sasi before using them.

regards,
Mick

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



Re: Warn about SASI usage and allow to disable them

2019-01-16 Thread Andrés de la Peña
Thanks for the feedback.
It seems we agree to the config property, disabled by default in trunk.
Regarding the warning, we might add it at least in 3.11, since for that
version the property to enable SASI is going to be present but not disabled
by default. WDYT?

On Tue, 15 Jan 2019 at 11:24, Benjamin Lerer 
wrote:

>  +1 on config. +1 on disabling by default
>
> On Tue, Jan 15, 2019 at 6:51 AM Jeff Jirsa  wrote:
>
> > +1 on config
> > -0 on warning
> > -0 on disabling by default
> >
> >
> > --
> > Jeff Jirsa
> >
> >
> > > On Jan 14, 2019, at 9:22 PM, Taylor Cressy 
> > wrote:
> > >
> > > +1 on config. +1 on disabling.
> > >
> > > +1 on applying it to materialized views as well.
> > >
> > >> On Jan 14, 2019, at 17:29, Joshua McKenzie 
> > wrote:
> > >>
> > >> +1 on config change, +1 on disabling, and so long as the comments make
> > the
> > >> limitations and risks extremely clear, I'm fine w/out the client
> > warning.
> > >>
> > >> On Mon, Jan 14, 2019 at 12:28 PM Andrés de la Peña <
> > a.penya.gar...@gmail.com>
> > >> wrote:
> > >>
> > >>> I mean disabling the creation of new SASI indices with CREATE INDEX
> > >>> statement, the existing indexes would continue working. The CQL
> client
> > >>> warning will be thrown with that creation statement as well (if they
> > are
> > >>> enabled).
> > >>>
> >  On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa  wrote:
> > 
> >  When we say disable, do you mean disable creation of new SASI
> > indices, or
> >  disable using existing ones? I assume it's just creation of new?
> > 
> >  On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña <
> >  a.penya.gar...@gmail.com>
> >  wrote:
> > 
> > > Hello all,
> > >
> > > It is my understanding that SASI is still to be considered an
> > > experimental/beta feature, and they apparently are not being very
> >  actively
> > > developed. Some higlighted problems in SASI are:
> > >
> > > - OOMs during flush, as it is described in CASSANDRA-12662
> > > - General secondary index consistency problems described in
> >  CASSANDRA-8272.
> > > There is a pending-review patch addressing the problem for regular
> > 2i.
> > > However, the proposed solution is based on indexing tombstones.
> SASI
> > > doesn't index tombstones, so it wouldn't be enterely trivial to
> > extend
> >  the
> > > approach to SASI.
> > > - Probably insufficient testing. As far as I know, we don't have a
> > >>> single
> > > dtest for SASI nor tests dealing with large SSTables.
> > >
> > > Similarly to what CASSANDRA-13959 did with materialized views,
> > > CASSANDRA-14866 aims to throw a native protocol warning about SASI
> > > experimental state, and to add a config property to disable them.
> > >>> Perhaps
> > > this property could be disabled by default in trunk. This should
> > raise
> > > awareness about SASI maturity until we let them in a more stable
> > state.
> > >
> > > The purpose for this thread is discussing whether we want to add
> this
> > > warning, the config property and, more controversially, if we want
> to
> > >>> set
> > > SASI as disabled by default in trunk.
> > >
> > > WDYT?
> > >
> > 
> > >>>
> > >
> > > -
> > > 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: Warn about SASI usage and allow to disable them

2019-01-15 Thread Benjamin Lerer
 +1 on config. +1 on disabling by default

On Tue, Jan 15, 2019 at 6:51 AM Jeff Jirsa  wrote:

> +1 on config
> -0 on warning
> -0 on disabling by default
>
>
> --
> Jeff Jirsa
>
>
> > On Jan 14, 2019, at 9:22 PM, Taylor Cressy 
> wrote:
> >
> > +1 on config. +1 on disabling.
> >
> > +1 on applying it to materialized views as well.
> >
> >> On Jan 14, 2019, at 17:29, Joshua McKenzie 
> wrote:
> >>
> >> +1 on config change, +1 on disabling, and so long as the comments make
> the
> >> limitations and risks extremely clear, I'm fine w/out the client
> warning.
> >>
> >> On Mon, Jan 14, 2019 at 12:28 PM Andrés de la Peña <
> a.penya.gar...@gmail.com>
> >> wrote:
> >>
> >>> I mean disabling the creation of new SASI indices with CREATE INDEX
> >>> statement, the existing indexes would continue working. The CQL client
> >>> warning will be thrown with that creation statement as well (if they
> are
> >>> enabled).
> >>>
>  On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa  wrote:
> 
>  When we say disable, do you mean disable creation of new SASI
> indices, or
>  disable using existing ones? I assume it's just creation of new?
> 
>  On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña <
>  a.penya.gar...@gmail.com>
>  wrote:
> 
> > Hello all,
> >
> > It is my understanding that SASI is still to be considered an
> > experimental/beta feature, and they apparently are not being very
>  actively
> > developed. Some higlighted problems in SASI are:
> >
> > - OOMs during flush, as it is described in CASSANDRA-12662
> > - General secondary index consistency problems described in
>  CASSANDRA-8272.
> > There is a pending-review patch addressing the problem for regular
> 2i.
> > However, the proposed solution is based on indexing tombstones. SASI
> > doesn't index tombstones, so it wouldn't be enterely trivial to
> extend
>  the
> > approach to SASI.
> > - Probably insufficient testing. As far as I know, we don't have a
> >>> single
> > dtest for SASI nor tests dealing with large SSTables.
> >
> > Similarly to what CASSANDRA-13959 did with materialized views,
> > CASSANDRA-14866 aims to throw a native protocol warning about SASI
> > experimental state, and to add a config property to disable them.
> >>> Perhaps
> > this property could be disabled by default in trunk. This should
> raise
> > awareness about SASI maturity until we let them in a more stable
> state.
> >
> > The purpose for this thread is discussing whether we want to add this
> > warning, the config property and, more controversially, if we want to
> >>> set
> > SASI as disabled by default in trunk.
> >
> > WDYT?
> >
> 
> >>>
> >
> > -
> > 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: Warn about SASI usage and allow to disable them

2019-01-14 Thread Jeff Jirsa
+1 on config
-0 on warning 
-0 on disabling by default


-- 
Jeff Jirsa


> On Jan 14, 2019, at 9:22 PM, Taylor Cressy  wrote:
> 
> +1 on config. +1 on disabling. 
> 
> +1 on applying it to materialized views as well. 
> 
>> On Jan 14, 2019, at 17:29, Joshua McKenzie  wrote:
>> 
>> +1 on config change, +1 on disabling, and so long as the comments make the
>> limitations and risks extremely clear, I'm fine w/out the client warning.
>> 
>> On Mon, Jan 14, 2019 at 12:28 PM Andrés de la Peña 
>> wrote:
>> 
>>> I mean disabling the creation of new SASI indices with CREATE INDEX
>>> statement, the existing indexes would continue working. The CQL client
>>> warning will be thrown with that creation statement as well (if they are
>>> enabled).
>>> 
 On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa  wrote:
 
 When we say disable, do you mean disable creation of new SASI indices, or
 disable using existing ones? I assume it's just creation of new?
 
 On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña <
 a.penya.gar...@gmail.com>
 wrote:
 
> Hello all,
> 
> It is my understanding that SASI is still to be considered an
> experimental/beta feature, and they apparently are not being very
 actively
> developed. Some higlighted problems in SASI are:
> 
> - OOMs during flush, as it is described in CASSANDRA-12662
> - General secondary index consistency problems described in
 CASSANDRA-8272.
> There is a pending-review patch addressing the problem for regular 2i.
> However, the proposed solution is based on indexing tombstones. SASI
> doesn't index tombstones, so it wouldn't be enterely trivial to extend
 the
> approach to SASI.
> - Probably insufficient testing. As far as I know, we don't have a
>>> single
> dtest for SASI nor tests dealing with large SSTables.
> 
> Similarly to what CASSANDRA-13959 did with materialized views,
> CASSANDRA-14866 aims to throw a native protocol warning about SASI
> experimental state, and to add a config property to disable them.
>>> Perhaps
> this property could be disabled by default in trunk. This should raise
> awareness about SASI maturity until we let them in a more stable state.
> 
> The purpose for this thread is discussing whether we want to add this
> warning, the config property and, more controversially, if we want to
>>> set
> SASI as disabled by default in trunk.
> 
> WDYT?
> 
 
>>> 
> 
> -
> 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: Warn about SASI usage and allow to disable them

2019-01-14 Thread Jasonstack Zhao Yang
+1 on yaml config. +1 on disable by default.

On Tue, 15 Jan 2019 at 13:23 Taylor Cressy  wrote:

> +1 on config. +1 on disabling.
>
> +1 on applying it to materialized views as well.
>
> > On Jan 14, 2019, at 17:29, Joshua McKenzie  wrote:
> >
> > +1 on config change, +1 on disabling, and so long as the comments make
> the
> > limitations and risks extremely clear, I'm fine w/out the client warning.
> >
> > On Mon, Jan 14, 2019 at 12:28 PM Andrés de la Peña <
> a.penya.gar...@gmail.com>
> > wrote:
> >
> >> I mean disabling the creation of new SASI indices with CREATE INDEX
> >> statement, the existing indexes would continue working. The CQL client
> >> warning will be thrown with that creation statement as well (if they are
> >> enabled).
> >>
> >>> On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa  wrote:
> >>>
> >>> When we say disable, do you mean disable creation of new SASI indices,
> or
> >>> disable using existing ones? I assume it's just creation of new?
> >>>
> >>> On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña <
> >>> a.penya.gar...@gmail.com>
> >>> wrote:
> >>>
>  Hello all,
> 
>  It is my understanding that SASI is still to be considered an
>  experimental/beta feature, and they apparently are not being very
> >>> actively
>  developed. Some higlighted problems in SASI are:
> 
>  - OOMs during flush, as it is described in CASSANDRA-12662
>  - General secondary index consistency problems described in
> >>> CASSANDRA-8272.
>  There is a pending-review patch addressing the problem for regular 2i.
>  However, the proposed solution is based on indexing tombstones. SASI
>  doesn't index tombstones, so it wouldn't be enterely trivial to extend
> >>> the
>  approach to SASI.
>  - Probably insufficient testing. As far as I know, we don't have a
> >> single
>  dtest for SASI nor tests dealing with large SSTables.
> 
>  Similarly to what CASSANDRA-13959 did with materialized views,
>  CASSANDRA-14866 aims to throw a native protocol warning about SASI
>  experimental state, and to add a config property to disable them.
> >> Perhaps
>  this property could be disabled by default in trunk. This should raise
>  awareness about SASI maturity until we let them in a more stable
> state.
> 
>  The purpose for this thread is discussing whether we want to add this
>  warning, the config property and, more controversially, if we want to
> >> set
>  SASI as disabled by default in trunk.
> 
>  WDYT?
> 
> >>>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Taylor Cressy
+1 on config. +1 on disabling. 

+1 on applying it to materialized views as well. 

> On Jan 14, 2019, at 17:29, Joshua McKenzie  wrote:
> 
> +1 on config change, +1 on disabling, and so long as the comments make the
> limitations and risks extremely clear, I'm fine w/out the client warning.
> 
> On Mon, Jan 14, 2019 at 12:28 PM Andrés de la Peña 
> wrote:
> 
>> I mean disabling the creation of new SASI indices with CREATE INDEX
>> statement, the existing indexes would continue working. The CQL client
>> warning will be thrown with that creation statement as well (if they are
>> enabled).
>> 
>>> On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa  wrote:
>>> 
>>> When we say disable, do you mean disable creation of new SASI indices, or
>>> disable using existing ones? I assume it's just creation of new?
>>> 
>>> On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña <
>>> a.penya.gar...@gmail.com>
>>> wrote:
>>> 
 Hello all,
 
 It is my understanding that SASI is still to be considered an
 experimental/beta feature, and they apparently are not being very
>>> actively
 developed. Some higlighted problems in SASI are:
 
 - OOMs during flush, as it is described in CASSANDRA-12662
 - General secondary index consistency problems described in
>>> CASSANDRA-8272.
 There is a pending-review patch addressing the problem for regular 2i.
 However, the proposed solution is based on indexing tombstones. SASI
 doesn't index tombstones, so it wouldn't be enterely trivial to extend
>>> the
 approach to SASI.
 - Probably insufficient testing. As far as I know, we don't have a
>> single
 dtest for SASI nor tests dealing with large SSTables.
 
 Similarly to what CASSANDRA-13959 did with materialized views,
 CASSANDRA-14866 aims to throw a native protocol warning about SASI
 experimental state, and to add a config property to disable them.
>> Perhaps
 this property could be disabled by default in trunk. This should raise
 awareness about SASI maturity until we let them in a more stable state.
 
 The purpose for this thread is discussing whether we want to add this
 warning, the config property and, more controversially, if we want to
>> set
 SASI as disabled by default in trunk.
 
 WDYT?
 
>>> 
>> 

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



Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Joshua McKenzie
+1 on config change, +1 on disabling, and so long as the comments make the
limitations and risks extremely clear, I'm fine w/out the client warning.

On Mon, Jan 14, 2019 at 12:28 PM Andrés de la Peña 
wrote:

> I mean disabling the creation of new SASI indices with CREATE INDEX
> statement, the existing indexes would continue working. The CQL client
> warning will be thrown with that creation statement as well (if they are
> enabled).
>
> On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa  wrote:
>
> > When we say disable, do you mean disable creation of new SASI indices, or
> > disable using existing ones? I assume it's just creation of new?
> >
> > On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña <
> > a.penya.gar...@gmail.com>
> > wrote:
> >
> > > Hello all,
> > >
> > > It is my understanding that SASI is still to be considered an
> > > experimental/beta feature, and they apparently are not being very
> > actively
> > > developed. Some higlighted problems in SASI are:
> > >
> > > - OOMs during flush, as it is described in CASSANDRA-12662
> > > - General secondary index consistency problems described in
> > CASSANDRA-8272.
> > > There is a pending-review patch addressing the problem for regular 2i.
> > > However, the proposed solution is based on indexing tombstones. SASI
> > > doesn't index tombstones, so it wouldn't be enterely trivial to extend
> > the
> > > approach to SASI.
> > > - Probably insufficient testing. As far as I know, we don't have a
> single
> > > dtest for SASI nor tests dealing with large SSTables.
> > >
> > > Similarly to what CASSANDRA-13959 did with materialized views,
> > > CASSANDRA-14866 aims to throw a native protocol warning about SASI
> > > experimental state, and to add a config property to disable them.
> Perhaps
> > > this property could be disabled by default in trunk. This should raise
> > > awareness about SASI maturity until we let them in a more stable state.
> > >
> > > The purpose for this thread is discussing whether we want to add this
> > > warning, the config property and, more controversially, if we want to
> set
> > > SASI as disabled by default in trunk.
> > >
> > > WDYT?
> > >
> >
>


Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Andrés de la Peña
I mean disabling the creation of new SASI indices with CREATE INDEX
statement, the existing indexes would continue working. The CQL client
warning will be thrown with that creation statement as well (if they are
enabled).

On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa  wrote:

> When we say disable, do you mean disable creation of new SASI indices, or
> disable using existing ones? I assume it's just creation of new?
>
> On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña <
> a.penya.gar...@gmail.com>
> wrote:
>
> > Hello all,
> >
> > It is my understanding that SASI is still to be considered an
> > experimental/beta feature, and they apparently are not being very
> actively
> > developed. Some higlighted problems in SASI are:
> >
> > - OOMs during flush, as it is described in CASSANDRA-12662
> > - General secondary index consistency problems described in
> CASSANDRA-8272.
> > There is a pending-review patch addressing the problem for regular 2i.
> > However, the proposed solution is based on indexing tombstones. SASI
> > doesn't index tombstones, so it wouldn't be enterely trivial to extend
> the
> > approach to SASI.
> > - Probably insufficient testing. As far as I know, we don't have a single
> > dtest for SASI nor tests dealing with large SSTables.
> >
> > Similarly to what CASSANDRA-13959 did with materialized views,
> > CASSANDRA-14866 aims to throw a native protocol warning about SASI
> > experimental state, and to add a config property to disable them. Perhaps
> > this property could be disabled by default in trunk. This should raise
> > awareness about SASI maturity until we let them in a more stable state.
> >
> > The purpose for this thread is discussing whether we want to add this
> > warning, the config property and, more controversially, if we want to set
> > SASI as disabled by default in trunk.
> >
> > WDYT?
> >
>


Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Jeff Jirsa
When we say disable, do you mean disable creation of new SASI indices, or
disable using existing ones? I assume it's just creation of new?

On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña 
wrote:

> Hello all,
>
> It is my understanding that SASI is still to be considered an
> experimental/beta feature, and they apparently are not being very actively
> developed. Some higlighted problems in SASI are:
>
> - OOMs during flush, as it is described in CASSANDRA-12662
> - General secondary index consistency problems described in CASSANDRA-8272.
> There is a pending-review patch addressing the problem for regular 2i.
> However, the proposed solution is based on indexing tombstones. SASI
> doesn't index tombstones, so it wouldn't be enterely trivial to extend the
> approach to SASI.
> - Probably insufficient testing. As far as I know, we don't have a single
> dtest for SASI nor tests dealing with large SSTables.
>
> Similarly to what CASSANDRA-13959 did with materialized views,
> CASSANDRA-14866 aims to throw a native protocol warning about SASI
> experimental state, and to add a config property to disable them. Perhaps
> this property could be disabled by default in trunk. This should raise
> awareness about SASI maturity until we let them in a more stable state.
>
> The purpose for this thread is discussing whether we want to add this
> warning, the config property and, more controversially, if we want to set
> SASI as disabled by default in trunk.
>
> WDYT?
>


Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Brandon Williams
I amend to +1 everything except warning, which I'm +0 on.

On Mon, Jan 14, 2019 at 1:59 PM Caleb Rackliffe 
wrote:

> +1 to config and disable
>
> On Mon, Jan 14, 2019, 1:54 PM Mick Semb Wever 
> >
> >
> > > The purpose for this thread is discussing whether we want to add this
> > > warning, the config property and, more controversially, if we want to
> set
> > > SASI as disabled by default in trunk.
> >
> >
> > I'm +1 on everything, except the warning.
> >
> > I think if we add the config property and it's disabled in trunk then
> > we're done enough.
> > Existing users should be ok.
> >
> > regards,
> > Mick
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>


Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Caleb Rackliffe
+1 to config and disable

On Mon, Jan 14, 2019, 1:54 PM Mick Semb Wever 
>
> > The purpose for this thread is discussing whether we want to add this
> > warning, the config property and, more controversially, if we want to set
> > SASI as disabled by default in trunk.
>
>
> I'm +1 on everything, except the warning.
>
> I think if we add the config property and it's disabled in trunk then
> we're done enough.
> Existing users should be ok.
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Mick Semb Wever



> The purpose for this thread is discussing whether we want to add this
> warning, the config property and, more controversially, if we want to set
> SASI as disabled by default in trunk.


I'm +1 on everything, except the warning.

I think if we add the config property and it's disabled in trunk then we're 
done enough.
Existing users should be ok.

regards,
Mick

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



Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Brandon Williams
+1 to warn, config, and disable.

On Mon, Jan 14, 2019 at 1:45 PM Jonathan Haddad  wrote:

> I'm very much in favor of a warning, and I lean towards disabling them (and
> MVs, while we're at it) by default as well.
>
> I've seen both features be the death of clusters, and are a major risk for
> teams that are brand new to Cassandra.
>
>
>
> On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña <
> a.penya.gar...@gmail.com>
> wrote:
>
> > Hello all,
> >
> > It is my understanding that SASI is still to be considered an
> > experimental/beta feature, and they apparently are not being very
> actively
> > developed. Some higlighted problems in SASI are:
> >
> > - OOMs during flush, as it is described in CASSANDRA-12662
> > - General secondary index consistency problems described in
> CASSANDRA-8272.
> > There is a pending-review patch addressing the problem for regular 2i.
> > However, the proposed solution is based on indexing tombstones. SASI
> > doesn't index tombstones, so it wouldn't be enterely trivial to extend
> the
> > approach to SASI.
> > - Probably insufficient testing. As far as I know, we don't have a single
> > dtest for SASI nor tests dealing with large SSTables.
> >
> > Similarly to what CASSANDRA-13959 did with materialized views,
> > CASSANDRA-14866 aims to throw a native protocol warning about SASI
> > experimental state, and to add a config property to disable them. Perhaps
> > this property could be disabled by default in trunk. This should raise
> > awareness about SASI maturity until we let them in a more stable state.
> >
> > The purpose for this thread is discussing whether we want to add this
> > warning, the config property and, more controversially, if we want to set
> > SASI as disabled by default in trunk.
> >
> > WDYT?
> >
>
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>


Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Jonathan Haddad
I'm very much in favor of a warning, and I lean towards disabling them (and
MVs, while we're at it) by default as well.

I've seen both features be the death of clusters, and are a major risk for
teams that are brand new to Cassandra.



On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña 
wrote:

> Hello all,
>
> It is my understanding that SASI is still to be considered an
> experimental/beta feature, and they apparently are not being very actively
> developed. Some higlighted problems in SASI are:
>
> - OOMs during flush, as it is described in CASSANDRA-12662
> - General secondary index consistency problems described in CASSANDRA-8272.
> There is a pending-review patch addressing the problem for regular 2i.
> However, the proposed solution is based on indexing tombstones. SASI
> doesn't index tombstones, so it wouldn't be enterely trivial to extend the
> approach to SASI.
> - Probably insufficient testing. As far as I know, we don't have a single
> dtest for SASI nor tests dealing with large SSTables.
>
> Similarly to what CASSANDRA-13959 did with materialized views,
> CASSANDRA-14866 aims to throw a native protocol warning about SASI
> experimental state, and to add a config property to disable them. Perhaps
> this property could be disabled by default in trunk. This should raise
> awareness about SASI maturity until we let them in a more stable state.
>
> The purpose for this thread is discussing whether we want to add this
> warning, the config property and, more controversially, if we want to set
> SASI as disabled by default in trunk.
>
> WDYT?
>


-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade


Warn about SASI usage and allow to disable them

2019-01-14 Thread Andrés de la Peña
Hello all,

It is my understanding that SASI is still to be considered an
experimental/beta feature, and they apparently are not being very actively
developed. Some higlighted problems in SASI are:

- OOMs during flush, as it is described in CASSANDRA-12662
- General secondary index consistency problems described in CASSANDRA-8272.
There is a pending-review patch addressing the problem for regular 2i.
However, the proposed solution is based on indexing tombstones. SASI
doesn't index tombstones, so it wouldn't be enterely trivial to extend the
approach to SASI.
- Probably insufficient testing. As far as I know, we don't have a single
dtest for SASI nor tests dealing with large SSTables.

Similarly to what CASSANDRA-13959 did with materialized views,
CASSANDRA-14866 aims to throw a native protocol warning about SASI
experimental state, and to add a config property to disable them. Perhaps
this property could be disabled by default in trunk. This should raise
awareness about SASI maturity until we let them in a more stable state.

The purpose for this thread is discussing whether we want to add this
warning, the config property and, more controversially, if we want to set
SASI as disabled by default in trunk.

WDYT?