[jira] [Comment Edited] (CASSANDRA-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418233#comment-17418233
]
Josh McKenzie edited comment on CASSANDRA-12988 at 9/21/21, 5:50 PM:
-
[Added a
commit|https://github.com/apache/cassandra/commit/28ad1f8209e06da705f09bff19879619d5e77f55]
that reverts to identical pre-commit CL special-case handling of the default
super user account along with some better documentation around what we're doing
and why so we don't run into this in the future. Plus a unit test to further
harden against accidental changing of this in the future.
I'm tempted to say we should cut all access to
CassandraAuthorizer.auth*ConsistencyLevel and route everything through the role
methods, but people can go straight to the AuthProperties object anyway and
pull CL for read/write w/out respecting role-specific needs if they're really
hell-bent on living on the edge.
Edit: Quick addendum - I'm all for us changing things so we don't have this
strange one-off default behavior for the edge-case with the "cassandra" default
role, optionally disabling its default creation, etc. But the goal of _this_
ticket is the ability to flexibly configure read and write CL for auth, not to
make changes to that default role-based behavior, hence reverting to the
"better documented form of the previous behavior" approach.
was (Author: jmckenzie):
[Added a
commit|https://github.com/apache/cassandra/commit/28ad1f8209e06da705f09bff19879619d5e77f55]
that reverts to identical pre-commit CL special-case handling of the default
super user account along with some better documentation around what we're doing
and why so we don't run into this in the future. Plus a unit test to further
harden against accidental changing of this in the future.
I'm tempted to say we should cut all access to
CassandraAuthorizer.auth*ConsistencyLevel and route everything through the role
methods, but people can go straight to the AuthProperties object anyway and
pull CL for read/write w/out respecting role-specific needs if they're really
hell-bent on living on the edge.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416793#comment-17416793
]
Jeremiah Jordan edited comment on CASSANDRA-12988 at 9/17/21, 4:38 PM:
---
Yes, keeping QUORUM for that would solve the auto create issue.
-Just thought of another issue. In the wild people will very often set the RF
of the auth key space to be equal to the number of nodes in the DC. I have
seen people set it to 12 or even higher in a single DC. They do this to make
the LOCAL_ONE query able to always be to the current node, lowering the chances
of auth failures from other nodes being slow. Switching to always using
LOCAL_QUORUM will go very badly in these cases.-
-I would suggest we need to be able to keep the LOCAL_ONE query as an option.-
Just re-read the patch and it kept the
auth_read_consistency_level/auth_write_consistency_level settings to pick the
level in the yaml, it seemed like that was not there from the JIRA comments.
That should be fine.
was (Author: jjordan):
Yes, keeping QUORUM for that would solve the auto create issue.
-Just thought of another issue. In the wild people will very often set the RF
of the auth key space to be equal to the number of nodes in the DC. I have
seen people set it to 12 or even higher in a single DC. They do this to make
the LOCAL_ONE query able to always be to the current node, lowering the chances
of auth failures from other nodes being slow. Switching to always using
LOCAL_QUORUM will go very badly in these cases.
I would suggest we need to be able to keep the LOCAL_ONE query as an option.-
Just re-read the patch and it kept the
auth_read_consistency_level/auth_write_consistency_level settings to pick the
level in the yaml, it seemed like that was not there from the JIRA comments.
That should be fine.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416793#comment-17416793
]
Jeremiah Jordan edited comment on CASSANDRA-12988 at 9/17/21, 4:38 PM:
---
Yes, keeping QUORUM for that would solve the auto create issue.
-Just thought of another issue. In the wild people will very often set the RF
of the auth key space to be equal to the number of nodes in the DC. I have
seen people set it to 12 or even higher in a single DC. They do this to make
the LOCAL_ONE query able to always be to the current node, lowering the chances
of auth failures from other nodes being slow. Switching to always using
LOCAL_QUORUM will go very badly in these cases.
I would suggest we need to be able to keep the LOCAL_ONE query as an option.-
Just re-read the patch and it kept the
auth_read_consistency_level/auth_write_consistency_level settings to pick the
level in the yaml, it seemed like that was not there from the JIRA comments.
That should be fine.
was (Author: jjordan):
Yes, keeping QUORUM for that would solve the auto create issue.
Just thought of another issue. In the wild people will very often set the RF
of the auth key space to be equal to the number of nodes in the DC. I have
seen people set it to 12 or even higher in a single DC. They do this to make
the LOCAL_ONE query able to always be to the current node, lowering the chances
of auth failures from other nodes being slow. Switching to always using
LOCAL_QUORUM will go very badly in these cases.
I would suggest we need to be able to keep the LOCAL_ONE query as an option.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416761#comment-17416761
]
Jeremiah Jordan edited comment on CASSANDRA-12988 at 9/17/21, 3:31 PM:
---
I have not gone through the implications of this change extensively, but from
past experience with auth bootstrapping and multiple DC's, I do not know
changing away from QUORUM for the default user is safe.
Because of the way people bring up new datacenter with bootstrap off, combined
with the way we auto create the "cassandra" users, I do not think it is safe to
stop using QUORUM for that user. A read at LOCAL_QUORUM will not find any
users and the nodes would then "create" the "cassandra" user, possibly over
writing or bringing that user back if it removed.
I hate the fact that the "cassandra" user uses QUORUM as much as the next
person, but until we have a way to create that user which is not "try to do it
automatically during first startup", or we don't have "auto bootstrap:false" as
an option, I think the use of QUORUM is actually needed.
was (Author: jjordan):
I have not gone through the implications of this change extensively, but from
past experience with auth bootstrapping and multiple DC's, I do not know
changing away from QUORUM is safe.
Because of the way people bring up new datacenter with bootstrap off, combined
with the way we auto create the "cassandra" users, I do not think it is safe to
stop using QUORUM for that user. A read at LOCAL_QUORUM will not find any
users and the nodes would then "create" the "cassandra" user, possibly over
writing or bringing that user back if it removed.
I hate the fact that the "cassandra" user uses QUORUM as much as the next
person, but until we have a way to create that user which is not "try to do it
automatically during first startup", or we don't have "auto bootstrap:false" as
an option, I think the use of QUORUM is actually needed.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411899#comment-17411899
]
Josh McKenzie edited comment on CASSANDRA-12988 at 9/8/21, 12:40 PM:
-
Some dtest failures that look related to the slight changes in CL defaults that
come along w/the shape of the patch. Bouncing back to in progress while I work
through those as I'm not sure how invasive those changes will end up.
edit: just saw that you picked this up [~b.le...@gmail.com]; I'll keep things
as they are on the Jira here and ping when I've rooted this out.
was (Author: jmckenzie):
Some dtest failures that look related to the slight changes in CL defaults that
come along w/the shape of the patch. Bouncing back to in progress while I work
through those as I'm not sure how invasive those changes will end up.
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
