[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14315214#comment-14315214 ] Aleksey Yeschenko commented on CASSANDRA-8754: -- I guess if we do implement the capability framework as a two-level one (limit on role+resource), then it is indeed fit. Until now I was in favor of a single-level one (only role + limit, not per=table/keyspace), which is why "and right now it doesn't to me". If we have an agreement now, should this just be closed as a dupe of CASSANDRA-8303? > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14315215#comment-14315215 ] Aleksey Yeschenko commented on CASSANDRA-8754: -- I guess if we do implement the capability framework as a two-level one (limit on role+resource), then it is indeed fit. Until now I was in favor of a single-level one (only role + limit, not per=table/keyspace), which is why "and right now it doesn't to me". If we have an agreement now, should this just be closed as a dupe of CASSANDRA-8303? > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14312035#comment-14312035 ] Sylvain Lebresne commented on CASSANDRA-8754: - bq. The biggest benefit would be to enforce sanity on LWT operations not mixing with non-LWT It's a good point, which does imply we need to separate reads and writes as non-LWT reads often make sense on LWT updated tables. bq. Alternatively, we could use the capability-limitation framework that we've discussed before, if that feels like a better fit Actually, it kind of does sound like capabillity limitation, and the framework we've discussed so far (CASSANDRA-8303) is per-table and distinguish reads and writes, both of which are desirable. It further adds the notion of roles which kind of make sense for this too. Further, said framework might be extended someday to include things like having default limitations for newly created tables, and this would also benefit to this feature. Overall, this is the option that makes the most sense to me (adding it as table options is simple but feels a bit more adhoc to me). > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309931#comment-14309931 ] Chris Lohfink commented on CASSANDRA-8754: -- I could see: # just create a Counter per CL type in CFMetrics that we can increment on read/writes. An AtomicLong increment isn't much overhead. # could throw it in the topK partitions profiler (then also rename nodetool command from topkpartitions to profile). like CASSANDRA-7974. Would only add overhead when people are interested then. > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309751#comment-14309751 ] Ryan Svihla commented on CASSANDRA-8754: Auditing would help with diagnosis, but it'd have to be cheap enough to turn it on. I still think there is a huge value for a number of users to have some server side CL restriction, I've been asked personally more than a few times. > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309737#comment-14309737 ] Aleksey Yeschenko commented on CASSANDRA-8754: -- I summon [~rlow] > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309702#comment-14309702 ] Jeremy Hanna commented on CASSANDRA-8754: - I was thinking of auditing as well. You could definitively tell which CL has been used for operations. Might be a lot of overhead though like tracing. > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309670#comment-14309670
]
Chris Lohfink commented on CASSANDRA-8754:
--
Would an auditing tool be good then? Something like
{code}
Keyspace.CF Top Consistency Levels:
ONE 100
QUORUM 2
LOCAL_ONE 0
{code}
could give more context to how they are used as well.
> Required consistency level
> --
>
> Key: CASSANDRA-8754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8754
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Ryan Svihla
> Labels: ponies
>
> Idea is to prevent a query based on a consistency level not being met. For
> example we can specify that all queries should be at least CL LOCAL_QUORUM.
> Lots of users struggle with getting all their dev teams on board with
> consistency levels and all the ramifications. The normal solution for this
> has traditionally to build a service in front of Cassandra that the entire
> dev team accesses. However, this has proven challenging for some
> organizations to do correctly, and I think an easier approach would be to
> require a given consistency level as a matter of enforced policy in the
> database.
> I'm open for where this belongs. The most flexible approach is at a table
> level, however I'm concerned this is potentially error prone and labor
> intensive. It could be a table attribute similar to compaction strategy.
> The simplest administratively is a cluster level, in say the cassandra.yaml
> The middle ground is at they keyspace level, the only downside I could
> foresee is keyspace explosion to fit involved minimum schemes. It could be a
> keyspace attribute such as replication strategy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309651#comment-14309651 ] Ryan Svihla commented on CASSANDRA-8754: Then their table will be changed..and I'll have a schema description to indicate such > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309652#comment-14309652 ] Ryan Svihla commented on CASSANDRA-8754: Then their table will be changed..and I'll have a schema description to indicate such > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309641#comment-14309641 ] Brandon Williams commented on CASSANDRA-8754: - They can just use the super user to allow the CL then. > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309634#comment-14309634 ] Wei Deng commented on CASSANDRA-8754: - +1 to Ryan. Especially when we are talking about reviewing code in all languages the Cassandra drivers support. > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309627#comment-14309627 ] Ryan Svihla commented on CASSANDRA-8754: People sneak it. Happened more than a few times. An artifact _helps_ immensily > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309623#comment-14309623 ] Brandon Williams commented on CASSANDRA-8754: - They can't be trusted to use consistency levels properly, but they can be trusted with a super user? > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309625#comment-14309625 ] Ryan Svihla commented on CASSANDRA-8754: Also in regards to the ponying of this. It may help to understand the all too common situation I have to help people with. Education of CL doesn't spread across diverse dev teams accessing the same cluster, and worse turnover is often high. So all new code has the potential to invalidate company policy. If we have some artifact that is reviewable in Cassandra, I can be certain quickly the issue isn't in them misunderstanding of what a Consistency Level is..or some rogue users logging in and doing stuff by hand. If we're just relying on code, I have to comb through all code that touches the database sever, and I have to be able to read said code, trust I've seen said code to be able to diagnose "the data isn't consistent problems". This can take an enormous amount of time, when reviewing say a schema file would take 2 minutes. > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309622#comment-14309622 ] Aleksey Yeschenko commented on CASSANDRA-8754: -- Sounds reasonable to me. I'd go for a per-table blacklist, however, just for implementation reasons. Alternatively, we could use the capability-limitation framework that we've discussed before, if that feels like a better fit (and right now it doesn't to me). > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309605#comment-14309605 ] Ryan Svihla commented on CASSANDRA-8754: Sure, it still opens up to people using the cassandra user for nefarious actions, and this is more about creating an invariant for a dataset itself. Really the default value should be no restrictions so it's really only about what users who care about this want. > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309599#comment-14309599 ] Brandon Williams commented on CASSANDRA-8754: - Perhaps a better way would be to limit it per-user, as a permission. Then people who don't need childproofing in their database can do what they want. > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > Labels: ponies > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of users struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309509#comment-14309509 ] Tupshin Harper commented on CASSANDRA-8754: --- something like a set of ALLOWED_CONSISTENCY_LEVELS (maybe separate ones for reads and writes?) per table. The biggest benefit would be to enforce sanity on LWT operations not mixing with non-LWT, but in general, useful to reduce the amount of rope users have to hang themselves with. > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > > Idea is to prevent a query based on a consistency level not being met. For > example we can specify that all queries should be at least CL LOCAL_QUORUM. > Lots of customers struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8754) Required consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14309493#comment-14309493 ] Tupshin Harper commented on CASSANDRA-8754: --- -1 on cluster level (too limiting, IMO), but big +1 for table level restrictions of CL > Required consistency level > -- > > Key: CASSANDRA-8754 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8754 > Project: Cassandra > Issue Type: New Feature >Reporter: Ryan Svihla > > Idea is to prevent a query based on a consistency level not being met. > Lots of customers struggle with getting all their dev teams on board with > consistency levels and all the ramifications. The normal solution for this > has traditionally to build a service in front of Cassandra that the entire > dev team accesses. However, this has proven challenging for some > organizations to do correctly, and I think an easier approach would be to > require a given consistency level as a matter of enforced policy in the > database. > I'm open for where this belongs. The most flexible approach is at a table > level, however I'm concerned this is potentially error prone and labor > intensive. It could be a table attribute similar to compaction strategy. > The simplest administratively is a cluster level, in say the cassandra.yaml > The middle ground is at they keyspace level, the only downside I could > foresee is keyspace explosion to fit involved minimum schemes. It could be a > keyspace attribute such as replication strategy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
