[jira] [Commented] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826010#comment-17826010 ] Shailaja Koppu commented on CASSANDRA-19417: I have attached CI run results to this Jira. Checkstyle succeeded, but may not be evident in ci_summary.html, so ran checkstyle manually and attached the output. > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu updated CASSANDRA-19417: --- Attachment: result_details.tar.gz > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu updated CASSANDRA-19417: --- Attachment: ci_summary.html > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu updated CASSANDRA-19417: --- Attachment: checkstyle_output.txt > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Attachments: checkstyle_output.txt, ci_summary.html, > result_details.tar.gz > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825364#comment-17825364 ] Shailaja Koppu commented on CASSANDRA-19417: I ran CI before review comments, I will run again now with latest changes and will upload results > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824104#comment-17824104 ] Shailaja Koppu commented on CASSANDRA-19417: As there are no further comments on ML thread, continuing with PR for code changes. [~smiklosovic] I have merged all commits into one. [~maxwellguo] resolved your comments, as I merged all commits into one, you won't see a separate commit just resolving your comments. I have also added doc for this new CQL command. > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Time Spent: 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821765#comment-17821765 ] Shailaja Koppu commented on CASSANDRA-19417: Here is the ML discussion thread [https://lists.apache.org/thread/tmkdy09130t0538h768k65m927yvtrt9] > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Time Spent: 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821165#comment-17821165 ] Shailaja Koppu commented on CASSANDRA-19417: [~maxwellguo] [~smiklosovic] as per my understanding from this [https://docs.datastax.com/en/cql-oss/3.3/cql/cql_reference/cqlListUsers.html] LIST USERS command is deprecated. Do you mean adding option to LIST ROLES command? > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Time Spent: 20m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu updated CASSANDRA-19417: --- Change Category: Operability Labels: CQL (was: ) > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19417) LIST SUPERUSERS cql command
Shailaja Koppu created CASSANDRA-19417: -- Summary: LIST SUPERUSERS cql command Key: CASSANDRA-19417 URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 Project: Cassandra Issue Type: Improvement Components: Tool/cqlsh Reporter: Shailaja Koppu Assignee: Shailaja Koppu Developing a new CQL command LIST SUPERUSERS to return list of roles with superuser privilege. This includes roles who acquired superuser privilege in the hierarchy. Context: LIST ROLES cql command lists roles, their membership details and displays super=true for immediate superusers. But there can be roles who acquired superuser privilege due to a grant. LIST ROLES command won't display super=true for such roles and the only way to recognize such roles is to look for atleast one row with super=true in the output of LIST ROLES OF command. While this works to check is a given role has superuser privilege, there may be services (for example, Sidecar) working with C* and may need to maintain list of roles with superuser privilege. There is no existing command/tool to retrieve such roles details. Hence developing this command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18805) Upgrade caffeine to 3.1.8
[ https://issues.apache.org/jira/browse/CASSANDRA-18805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771082#comment-17771082 ] Shailaja Koppu commented on CASSANDRA-18805: I have sent +1 on PR > Upgrade caffeine to 3.1.8 > - > > Key: CASSANDRA-18805 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18805 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0.x, 5.x > > > 3.1.8 is based on Java 11. This version is testing with newer JDK versions, > while 2.x versions are based on JDK8, and as I understand, only bug-fix > releases are expected. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18805) Upgrade caffeine to 3.1.8
[
https://issues.apache.org/jira/browse/CASSANDRA-18805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767545#comment-17767545
]
Shailaja Koppu commented on CASSANDRA-18805:
Found a way. We can set high validity for cache, in the setup() before cache
gets created. Rest of the setup() code remains as it is.
@BeforeClass
public static void setup() throws Exception
{
DatabaseDescriptor.setRolesValidity(Integer.MAX_VALUE-1);
Once we do that, cache's expireAfterWrite gets set to 2147483646 ms, which is
596+ hours, i.e, 24+ days.
I will run the change under circle CI couple of times and let you know how it
goes.
> Upgrade caffeine to 3.1.8
> -
>
> Key: CASSANDRA-18805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18805
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> 3.1.8 is based on Java 11. This version is testing with newer JDK versions,
> while 2.x versions are based on JDK8, and as I understand, only bug-fix
> releases are expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18805) Upgrade caffeine to 3.1.8
[ https://issues.apache.org/jira/browse/CASSANDRA-18805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763830#comment-17763830 ] Shailaja Koppu commented on CASSANDRA-18805: I was making the test depend only on table read count to avoid being flaky. Table read count tells us that a cache entry was loaded from the table, without tightly depending on when/how the entry was invalidated. I believe that should be sufficient in the unit test. Also, this particular check cache.getIfPresent() was only to print descriptive message to the user when nodetool command is run. It doesn't impact the functionality. So I wouldn't be comfortable creating a flaky test disturbing circleCI/Jenkins builds and impacting developers time/efforts just for this minor message. > Upgrade caffeine to 3.1.8 > - > > Key: CASSANDRA-18805 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18805 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0.x, 5.x > > > 3.1.8 is based on Java 11. This version is testing with newer JDK versions, > while 2.x versions are based on JDK8, and as I understand, only bug-fix > releases are expected. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18805) Upgrade caffeine to 3.1.8
[ https://issues.apache.org/jira/browse/CASSANDRA-18805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763640#comment-17763640 ] Shailaja Koppu commented on CASSANDRA-18805: [~e.dimitrova] Sorry, having sick child at home. I have a minor comment in PR. I am worried about creating flaky test if we always expect entry to be in the cache by the time invalidation runs. > Upgrade caffeine to 3.1.8 > - > > Key: CASSANDRA-18805 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18805 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0.x, 5.x > > > 3.1.8 is based on Java 11. This version is testing with newer JDK versions, > while 2.x versions are based on JDK8, and as I understand, only bug-fix > releases are expected. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18805) Upgrade caffeine to 3.1.8
[ https://issues.apache.org/jira/browse/CASSANDRA-18805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762389#comment-17762389 ] Shailaja Koppu commented on CASSANDRA-18805: [~e.dimitrova] Sorry for the delayed response, I was on holidays. Thank you so much for taking care of this. The change to cache.getIfPresent(RoleResource.role(roleName)) seems correct to me. > Upgrade caffeine to 3.1.8 > - > > Key: CASSANDRA-18805 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18805 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0.x, 5.x > > > 3.1.8 is based on Java 11. This version is testing with newer JDK versions, > while 2.x versions are based on JDK8, and as I understand, only bug-fix > releases are expected. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18018) List command output not correct for super user, after grant command
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749452#comment-17749452
]
Shailaja Koppu commented on CASSANDRA-18018:
[~maximc] Sorry for the delayed response. LIST ROLES command already has a way
to tell is given user a superuser. Agree, not straightforward, but we can look
for atleast one True under 'super' column in the output. Problem is with LIST
permissions command (with or without on clause) which doesn't list all
permissions a superuser has and also doesn't say that given user is a
superuser, creating confusion to the reader.
Regarding fixing LIST permissions command, as we attempted to fix it and found
it's complicated involving various clauses and scenarios, and also LIST ROLES
command can be used before LIST permissions command to check for superuser
status, I am fine if you like to close this JIRA.
> List command output not correct for super user, after grant command
> ---
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Assignee: Maxim Chanturiay
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18592) CIDR filtering authorizer for Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-18592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740688#comment-17740688 ] Shailaja Koppu commented on CASSANDRA-18592: [~maxwellguo] I got to know that recommendation is one PR with multiple commits, each commit focusing on one part, so reviewers can conveniently review each commit. We will squash and merge those commits, so reverting will be easy if needed. I will follow that from next time onwards, currently most of the major logic is in one commit, splitting it into multiple commits takes time, hence will try that next time. > CIDR filtering authorizer for Cassandra > --- > > Key: CASSANDRA-18592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18592 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Authorization >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: authorization, cidr, features, security > Time Spent: 0.5h > Remaining Estimate: 0h > > Introducing a new authorizer, to allow or disallow users accesses based on > client's IP or CIDR group. Please see the confluence page for requirements > and detailed design of this feature > [https://cwiki.apache.org/confluence/display/CASSANDRA/CIDR+filtering+authorizer]. > Will post PR link and dev discussion soon. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18592) CIDR filtering authorizer for Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-18592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740684#comment-17740684 ] Shailaja Koppu commented on CASSANDRA-18592: Circle CI run - https://app.circleci.com/pipelines/github/skoppu22/cassandra/23 > CIDR filtering authorizer for Cassandra > --- > > Key: CASSANDRA-18592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18592 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Authorization >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: authorization, cidr, features, security > Time Spent: 0.5h > Remaining Estimate: 0h > > Introducing a new authorizer, to allow or disallow users accesses based on > client's IP or CIDR group. Please see the confluence page for requirements > and detailed design of this feature > [https://cwiki.apache.org/confluence/display/CASSANDRA/CIDR+filtering+authorizer]. > Will post PR link and dev discussion soon. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18592) CIDR filtering authorizer for Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-18592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17738466#comment-17738466 ] Shailaja Koppu commented on CASSANDRA-18592: Thanks [~maxwellguo] for going through this feature and sharing great feedback. We did all changes in one PR [https://github.com/apache/cassandra/pull/2414] because incase of any issues/escalations, it's easy to revert entire feature and associated code in one shot. > CIDR filtering authorizer for Cassandra > --- > > Key: CASSANDRA-18592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18592 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Authorization >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: authorization, cidr, features, security > Time Spent: 0.5h > Remaining Estimate: 0h > > Introducing a new authorizer, to allow or disallow users accesses based on > client's IP or CIDR group. Please see the confluence page for requirements > and detailed design of this feature > [https://cwiki.apache.org/confluence/display/CASSANDRA/CIDR+filtering+authorizer]. > Will post PR link and dev discussion soon. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18018) List command output not correct for super user, after grant command
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17734185#comment-17734185
]
Shailaja Koppu commented on CASSANDRA-18018:
[~samt] makes sense.
> List command output not correct for super user, after grant command
> ---
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Assignee: Maxim Chanturiay
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18592) CIDR filtering authorizer for Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-18592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu updated CASSANDRA-18592: --- Change Category: Operability Status: Open (was: Triage Needed) > CIDR filtering authorizer for Cassandra > --- > > Key: CASSANDRA-18592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18592 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Authorization >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: authorization, cidr, features, security > Time Spent: 0.5h > Remaining Estimate: 0h > > Introducing a new authorizer, to allow or disallow users accesses based on > client's IP or CIDR group. Please see the confluence page for requirements > and detailed design of this feature > [https://cwiki.apache.org/confluence/display/CASSANDRA/CIDR+filtering+authorizer]. > Will post PR link and dev discussion soon. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18592) CIDR filtering authorizer for Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-18592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu updated CASSANDRA-18592: --- Complexity: Normal Impacts: (was: None) Labels: authorization cidr features security (was: ) > CIDR filtering authorizer for Cassandra > --- > > Key: CASSANDRA-18592 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18592 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Authorization >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: authorization, cidr, features, security > > Introducing a new authorizer, to allow or disallow users accesses based on > client's IP or CIDR group. Please see the confluence page for requirements > and detailed design of this feature > [https://cwiki.apache.org/confluence/display/CASSANDRA/CIDR+filtering+authorizer.] > Will post PR link and dev discussion soon. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18592) CIDR filtering authorizer for Cassandra
Shailaja Koppu created CASSANDRA-18592: -- Summary: CIDR filtering authorizer for Cassandra Key: CASSANDRA-18592 URL: https://issues.apache.org/jira/browse/CASSANDRA-18592 Project: Cassandra Issue Type: New Feature Components: Feature/Authorization Reporter: Shailaja Koppu Assignee: Shailaja Koppu Introducing a new authorizer, to allow or disallow users accesses based on client's IP or CIDR group. Please see the confluence page for requirements and detailed design of this feature [https://cwiki.apache.org/confluence/display/CASSANDRA/CIDR+filtering+authorizer.] Will post PR link and dev discussion soon. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18018) List command output not correct for super user, after grant command
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715811#comment-17715811
]
Shailaja Koppu edited comment on CASSANDRA-18018 at 4/24/23 3:10 PM:
-
Discussed with [~samt] . We explored alternatives to achieve the above
mentioned scenario.
As an end user, I would like to have list permissions command simply say that
given user is a superuser, so the end user won't be confused with the empty or
incorrect output. Something like below:
{code:java}
cassandra@cqlsh> list all on system_auth.roles of cassandra;
'cassandra' is a superuser
{code}
But given the complexity involved in doing this, I will leave the decision to
[~maximc] . I am fine with not fixing this JIRA.
was (Author: JIRAUSER282877):
Discussed with [~samt] . We explored alternatives to achieve the above
mentioned scenario.
As an end user, I would like to have list permissions command simply say that
given user is a superuser, so the end user won't be confused with the empty or
incorrect output. Something like below:
cassandra@cqlsh> list all on system_auth.roles of cassandra;
'cassandra' is a superuser
But given the complexity involved in doing this, I will leave the decision to
[~maximc] . I am fine with not fixing this JIRA.
> List command output not correct for super user, after grant command
> ---
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18018) List command output not correct for super user, after grant command
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715811#comment-17715811
]
Shailaja Koppu commented on CASSANDRA-18018:
Discussed with [~samt] . We explored alternatives to achieve the above
mentioned scenario.
As an end user, I would like to have list permissions command simply say that
given user is a superuser, so the end user won't be confused with the empty or
incorrect output. Something like below:
cassandra@cqlsh> list all on system_auth.roles of cassandra;
'cassandra' is a superuser
But given the complexity involved in doing this, I will leave the decision to
[~maximc] . I am fine with not fixing this JIRA.
> List command output not correct for super user, after grant command
> ---
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18018) List command output not correct for super user, after grant command
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715755#comment-17715755
]
Shailaja Koppu commented on CASSANDRA-18018:
Let's assume we have a service which interacts with C* using list permissions
command to retrieve permissions of a user on a given keyspace/table and then
that service performs operations accordingly. This use case will break because
list permissions command behaves differently for superusers.
I understand the complexity involved in getting this command output right. I
like to have this command somehow indicate that given user is a super user, or
indicate that given user has all permissions. That way external services which
are interacting with C* don't have to make two trips, first to check is this a
superuser, then to check permissions for non-superusers.
Not only for this use case, even in general would be great if this command
simply says given user is a superuser. That way caller can simply assume all
permissions by seeing 'superuser' tag.
I am discussing with [~samt] offline regarding this use case, will get back to
you soon.
> List command output not correct for super user, after grant command
> ---
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18018) List command output not correct for super user, after grant command
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17682608#comment-17682608
]
Shailaja Koppu commented on CASSANDRA-18018:
I am reviewing it. I think best to get this reviewed from [~samt]
> List command output not correct for super user, after grant command
> ---
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Assignee: Maxim Chanturiay
>Priority: Normal
> Labels: lhf
> Fix For: 4.1.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18018) List command output not correct for super user, after grant command
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632364#comment-17632364
]
Shailaja Koppu commented on CASSANDRA-18018:
[~samt] reg
_I think that the confusion here mainly stems from the fact that superusers (in
C* as in pgsql) implicitly acquire ALL PERMISSIONS, because authz checks are
bypassed for them, whereas LIST PERMISSIONS and the system table which backs it
in the default implementation is concerned with explicitly granted permissions._
Agree, makes sense to store explicitly granted permissions. The problem is
currently list permissions command showing only explicitly granted permissions
after a grant command, I think list command can be improved to print all (both
implicitly and explicitly acquired) permissions that the role has. A typical
user expects LIST PERMISSIONS to list all permissions that the role has,
regardless of how they were acquired.
> List command output not correct for super user, after grant command
> ---
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Priority: Normal
> Labels: lhf
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18018) List command output not correct for super user, after grant command
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu updated CASSANDRA-18018:
---
Summary: List command output not correct for super user, after grant
command (was: List permissions output for a superuser, after grant command, is
not correct )
> List command output not correct for super user, after grant command
> ---
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Priority: Normal
> Labels: lhf
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18018) List permissions output for a superuser, after grant command, is not correct
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu updated CASSANDRA-18018:
---
Summary: List permissions output for a superuser, after grant command, is
not correct (was: List permissions output for superuser after grant command
is not correct )
> List permissions output for a superuser, after grant command, is not correct
> -
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Priority: Normal
> Labels: lhf
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18018) List permissions output for superuser after grant command is not correct
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu updated CASSANDRA-18018:
---
Description:
Running local Cassandra with below config:
{noformat}
authenticator: PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
network_authorizer: CassandraNetworkAuthorizer{noformat}
Created a super user and then ran *Grant select* command on a keyspace.
{noformat}
shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
SUPERUSER;
shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
datacenters;
{noformat}
After this, list permissions command showing only select permission for that
role on the resource.
{noformat}
shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
role | username | resource | permission
+---
shaadmin1c1 | shaadmin1c1 | | SELECT
{noformat}
Row in role_permissions table:
{noformat}
role | resource | permissions
--
shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
But insert command by that role on the resource is successful because role is a
super user
{noformat}
shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
shaadmin1c1@cqlsh> select * from testk1.t1 ;
c1 | c2
---+---
a | 1
(1 rows)
{noformat}
The problem is, output of list permissions command, which indicates only select
permission on the resource, is misleading. I think list command need to be
fixed to show all permissions super user has on the resource. Also grant
command for a super user can be either a no-op or throw error, because the role
already have requested permissions.
Documentation also misleading:
{quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
ROLES.
Superusers can only manage roles by default. To manage other resources,
{color:#ff}you must grant the permission set to that resource. **
{color}For example, to allow access management for all keyspaces: {{{}GRANT ALL
PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
{quote}
was:
Running local Cassandra with below config:
authenticator: PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
network_authorizer: CassandraNetworkAuthorizer
Created a super user and then ran *Grant select* command on a keyspace.
shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
SUPERUSER;
shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
datacenters;
After this, list permissions command showing only select permission for that
role on the resource.
shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
role| username| resource | permission
-+-+---+
shaadmin1c1 | shaadmin1c1 | | SELECT
Row in role_permissions table:
role| resource | permissions
-+---+--
shaadmin1c1 |data/testk1/t1 |
\{'SELECT'}
But insert command by that role on the resource is successful because role is a
super user
shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
shaadmin1c1@cqlsh> select * from testk1.t1 ;
c1 | c2
+
a | 1
(1 rows)
The problem is, output of list permissions command, which indicates only select
permission on the resource is misleading. I think list command need to be fixed
to show all permissions super user has on the resource. Also grant command for
a super user can be either a no-op or throw error, because the role already
have requested permissions.
Documentation also misleading:
{quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
ROLES.
Superusers can only manage roles by default. To manage other resources,
{color:#FF}you must grant the permission set to that resource. **
{color}For example, to allow access management for all keyspaces: {{GRANT ALL
PERMISSIONS ON ALL KEYSPACES TO }}{{{}*role_name*{}}}.{quote}
> List permissions output for superuser after grant command is not correct
> -
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Priority: Normal
>
> Running local Cassandra with below config:
> {noformat}
> authenticator:
[jira] [Updated] (CASSANDRA-18018) List permissions output for superuser after grant command is not correct
[
https://issues.apache.org/jira/browse/CASSANDRA-18018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu updated CASSANDRA-18018:
---
Labels: lhf (was: )
> List permissions output for superuser after grant command is not correct
> -
>
> Key: CASSANDRA-18018
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Shailaja Koppu
>Priority: Normal
> Labels: lhf
>
> Running local Cassandra with below config:
> {noformat}
> authenticator: PasswordAuthenticator
> authorizer: CassandraAuthorizer
> role_manager: CassandraRoleManager
> network_authorizer: CassandraNetworkAuthorizer{noformat}
> Created a super user and then ran *Grant select* command on a keyspace.
> {noformat}
> shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
> SUPERUSER;
> shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
> shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
> datacenters;
> {noformat}
>
> After this, list permissions command showing only select permission for that
> role on the resource.
> {noformat}
> shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
> role | username | resource | permission
> +---
> shaadmin1c1 | shaadmin1c1 | | SELECT
> {noformat}
>
> Row in role_permissions table:
> {noformat}
> role | resource | permissions
> --
> shaadmin1c1 | data/testk1/t1 | {'SELECT'}{noformat}
> But insert command by that role on the resource is successful because role is
> a super user
> {noformat}
> shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
> shaadmin1c1@cqlsh> select * from testk1.t1 ;
> c1 | c2
> ---+---
> a | 1
> (1 rows)
> {noformat}
>
> The problem is, output of list permissions command, which indicates only
> select permission on the resource, is misleading. I think list command need
> to be fixed to show all permissions super user has on the resource. Also
> grant command for a super user can be either a no-op or throw error, because
> the role already have requested permissions.
>
> Documentation also misleading:
> {quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
> ROLES.
> Superusers can only manage roles by default. To manage other resources,
> {color:#ff}you must grant the permission set to that resource. **
> {color}For example, to allow access management for all keyspaces: {{{}GRANT
> ALL PERMISSIONS ON ALL KEYSPACES TO }}\{{{}{*}role_name{*}{}}}.
> {quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18018) List permissions output for superuser after grant command is not correct
Shailaja Koppu created CASSANDRA-18018:
--
Summary: List permissions output for superuser after grant command
is not correct
Key: CASSANDRA-18018
URL: https://issues.apache.org/jira/browse/CASSANDRA-18018
Project: Cassandra
Issue Type: Bug
Components: Feature/Authorization
Reporter: Shailaja Koppu
Running local Cassandra with below config:
authenticator: PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
network_authorizer: CassandraNetworkAuthorizer
Created a super user and then ran *Grant select* command on a keyspace.
shaadmin1@cqlsh> CREATE USER 'shaadmin1c1' WITH PASSWORD 'shaadmin1c1'
SUPERUSER;
shaadmin1@cqlsh:system_auth> grant select on testk1.t1 to shaadmin1c1;
shaadmin1@cqlsh:system_auth> alter role shaadmin1c1 with access to all
datacenters;
After this, list permissions command showing only select permission for that
role on the resource.
shaadmin1c1@cqlsh> list all permissions of shaadmin1c1;
role| username| resource | permission
-+-+---+
shaadmin1c1 | shaadmin1c1 | | SELECT
Row in role_permissions table:
role| resource | permissions
-+---+--
shaadmin1c1 |data/testk1/t1 |
\{'SELECT'}
But insert command by that role on the resource is successful because role is a
super user
shaadmin1c1@cqlsh> insert into testk1.t1 (c1, c2) values ('a', 1);
shaadmin1c1@cqlsh> select * from testk1.t1 ;
c1 | c2
+
a | 1
(1 rows)
The problem is, output of list permissions command, which indicates only select
permission on the resource is misleading. I think list command need to be fixed
to show all permissions super user has on the resource. Also grant command for
a super user can be either a no-op or throw error, because the role already
have requested permissions.
Documentation also misleading:
{quote}True automatically grants AUTHORIZE, CREATE and DROP permission on ALL
ROLES.
Superusers can only manage roles by default. To manage other resources,
{color:#FF}you must grant the permission set to that resource. **
{color}For example, to allow access management for all keyspaces: {{GRANT ALL
PERMISSIONS ON ALL KEYSPACES TO }}{{{}*role_name*{}}}.{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17314) Test Failure: org.apache.cassandra.db.ScrubTest.testScrubCorruptedCounterRow
[
https://issues.apache.org/jira/browse/CASSANDRA-17314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17314:
--
Assignee: (was: Shailaja Koppu)
> Test Failure: org.apache.cassandra.db.ScrubTest.testScrubCorruptedCounterRow
>
>
> Key: CASSANDRA-17314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17314
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 3.0.x
>
>
> Failed 10 times in the last 14 runs. Flakiness: 61%, Stability: 28%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout.
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at jdk.nashorn.internal.scripts.Script$3$\^eval\_.:program(:13)
> at
> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637)
> at
> jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
> at
> jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155)
> at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at java.util.Vector.forEach(Vector.java:1277)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17314) Test Failure: org.apache.cassandra.db.ScrubTest.testScrubCorruptedCounterRow
[
https://issues.apache.org/jira/browse/CASSANDRA-17314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17314:
--
Assignee: Shailaja Koppu
> Test Failure: org.apache.cassandra.db.ScrubTest.testScrubCorruptedCounterRow
>
>
> Key: CASSANDRA-17314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17314
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Shailaja Koppu
>Priority: Normal
> Fix For: 3.0.x
>
>
> Failed 10 times in the last 14 runs. Flakiness: 61%, Stability: 28%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout.
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at java.util.Vector.forEach(Vector.java:1277)
> at jdk.nashorn.internal.scripts.Script$3$\^eval\_.:program(:13)
> at
> jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:637)
> at
> jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
> at
> jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:449)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:406)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:402)
> at
> jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:155)
> at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at java.util.Vector.forEach(Vector.java:1277)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17224) Add a virtual table for exposing prepared statements metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481155#comment-17481155
]
Shailaja Koppu edited comment on CASSANDRA-17224 at 1/24/22, 9:42 PM:
--
Fix is at
[https://github.com/apache/cassandra/pull/1421|https://github.com/apache/cassandra/pull/1421,]
please review.
was (Author: JIRAUSER282877):
Fix is at
[https://github.com/apache/cassandra/pull/1421|https://github.com/apache/cassandra/pull/1421,]
please review.
> Add a virtual table for exposing prepared statements metrics
>
>
> Key: CASSANDRA-17224
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17224
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics
>Reporter: Benjamin Lerer
>Assignee: Shailaja Koppu
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There are some existing metrics within {{CQLMetrics}} that provide metrics
> about prepared statements. We should expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example.
> The new table will need to be registered in {{SystemViewsKeyspace}}.
> Some unit tests will need to be added. For some example of virtual table
> tests you can look at {{SystemPropertiesTableTest}} and for some example of
> test around prepared statement metrics you can look into {{CQLMetricsTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17224) Add a virtual table for exposing prepared statements metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481155#comment-17481155
]
Shailaja Koppu edited comment on CASSANDRA-17224 at 1/24/22, 9:41 PM:
--
Fix is at
[https://github.com/apache/cassandra/pull/1421|https://github.com/apache/cassandra/pull/1421,]
please review.
was (Author: JIRAUSER282877):
Fix is at [https://github.com/apache/cassandra/pull/1421,] please review.
> Add a virtual table for exposing prepared statements metrics
>
>
> Key: CASSANDRA-17224
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17224
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics
>Reporter: Benjamin Lerer
>Assignee: Shailaja Koppu
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There are some existing metrics within {{CQLMetrics}} that provide metrics
> about prepared statements. We should expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example.
> The new table will need to be registered in {{SystemViewsKeyspace}}.
> Some unit tests will need to be added. For some example of virtual table
> tests you can look at {{SystemPropertiesTableTest}} and for some example of
> test around prepared statement metrics you can look into {{CQLMetricsTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17224) Add a virtual table for exposing prepared statements metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu updated CASSANDRA-17224:
---
Status: Patch Available (was: In Progress)
> Add a virtual table for exposing prepared statements metrics
>
>
> Key: CASSANDRA-17224
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17224
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics
>Reporter: Benjamin Lerer
>Assignee: Shailaja Koppu
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> There are some existing metrics within {{CQLMetrics}} that provide metrics
> about prepared statements. We should expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example.
> The new table will need to be registered in {{SystemViewsKeyspace}}.
> Some unit tests will need to be added. For some example of virtual table
> tests you can look at {{SystemPropertiesTableTest}} and for some example of
> test around prepared statement metrics you can look into {{CQLMetricsTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17224) Add a virtual table for exposing prepared statements metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu updated CASSANDRA-17224:
---
Status: In Progress (was: Patch Available)
> Add a virtual table for exposing prepared statements metrics
>
>
> Key: CASSANDRA-17224
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17224
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics
>Reporter: Benjamin Lerer
>Assignee: Shailaja Koppu
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> There are some existing metrics within {{CQLMetrics}} that provide metrics
> about prepared statements. We should expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example.
> The new table will need to be registered in {{SystemViewsKeyspace}}.
> Some unit tests will need to be added. For some example of virtual table
> tests you can look at {{SystemPropertiesTableTest}} and for some example of
> test around prepared statement metrics you can look into {{CQLMetricsTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17224) Add a virtual table for exposing prepared statements metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481158#comment-17481158
]
Shailaja Koppu commented on CASSANDRA-17224:
CircleCI run:
[https://app.circleci.com/pipelines/github/skoppu22/cassandra?invite=true]
Some tests failed, doesn't seem to be related to my code changes.
> Add a virtual table for exposing prepared statements metrics
>
>
> Key: CASSANDRA-17224
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17224
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics
>Reporter: Benjamin Lerer
>Assignee: Shailaja Koppu
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are some existing metrics within {{CQLMetrics}} that provide metrics
> about prepared statements. We should expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example.
> The new table will need to be registered in {{SystemViewsKeyspace}}.
> Some unit tests will need to be added. For some example of virtual table
> tests you can look at {{SystemPropertiesTableTest}} and for some example of
> test around prepared statement metrics you can look into {{CQLMetricsTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17224) Add a virtual table for exposing prepared statements metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu updated CASSANDRA-17224:
---
Test and Documentation Plan: https://github.com/apache/cassandra/pull/1421
Status: Patch Available (was: Open)
> Add a virtual table for exposing prepared statements metrics
>
>
> Key: CASSANDRA-17224
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17224
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics
>Reporter: Benjamin Lerer
>Assignee: Shailaja Koppu
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are some existing metrics within {{CQLMetrics}} that provide metrics
> about prepared statements. We should expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example.
> The new table will need to be registered in {{SystemViewsKeyspace}}.
> Some unit tests will need to be added. For some example of virtual table
> tests you can look at {{SystemPropertiesTableTest}} and for some example of
> test around prepared statement metrics you can look into {{CQLMetricsTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17224) Add a virtual table for exposing prepared statements metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481155#comment-17481155
]
Shailaja Koppu commented on CASSANDRA-17224:
Fix is at [https://github.com/apache/cassandra/pull/1421,] please review.
> Add a virtual table for exposing prepared statements metrics
>
>
> Key: CASSANDRA-17224
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17224
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics
>Reporter: Benjamin Lerer
>Assignee: Shailaja Koppu
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are some existing metrics within {{CQLMetrics}} that provide metrics
> about prepared statements. We should expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example.
> The new table will need to be registered in {{SystemViewsKeyspace}}.
> Some unit tests will need to be added. For some example of virtual table
> tests you can look at {{SystemPropertiesTableTest}} and for some example of
> test around prepared statement metrics you can look into {{CQLMetricsTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-6897) Add checksum to the Summary File and Bloom Filter file of SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu reassigned CASSANDRA-6897: - Assignee: Shailaja Koppu > Add checksum to the Summary File and Bloom Filter file of SSTables > -- > > Key: CASSANDRA-6897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6897 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: Adam Hattrell >Assignee: Shailaja Koppu >Priority: Normal > > Could we add a checksum to the Summary file and filter file of the SSTable. > Since reads the whole bloom filter before actually reading data, it seems > like it would make sense to checksum the bloom filter to make sure there is > no corruption there. Same is true with the summary file. The core of our > question is, can you add checksumming to all elements of the SSTable so if we > read anything corrupt we immediately see a failure? -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-11370) Display sstable count per level according to repair status on nodetool tablestats
[ https://issues.apache.org/jira/browse/CASSANDRA-11370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu reassigned CASSANDRA-11370: -- Assignee: Shailaja Koppu > Display sstable count per level according to repair status on nodetool > tablestats > - > > Key: CASSANDRA-11370 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11370 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Paulo Motta (Deprecated) >Assignee: Shailaja Koppu >Priority: Low > Labels: lhf > > After CASSANDRA-8004 we still display sstables in each level on nodetool > tablestats as if we had a single compaction strategy, while we have one > strategy for repaired and another for unrepaired data. > We should split display into repaired and unrepaired set, so this: > SSTables in each level: [2, 20/10, 15, 0, 0, 0, 0, 0, 0] > Would become: > SSTables in each level (repaired): [1, 10, 0, 0, 0, 0, 0, 0, 0] > SSTables in each level (unrepaired): [1, 10, 15, 0, 0, 0, 0, 0, 0] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17224) Add a virtual table for exposing prepared statements metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17224:
--
Assignee: Shailaja Koppu
> Add a virtual table for exposing prepared statements metrics
>
>
> Key: CASSANDRA-17224
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17224
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics
>Reporter: Benjamin Lerer
>Assignee: Shailaja Koppu
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> There are some existing metrics within {{CQLMetrics}} that provide metrics
> about prepared statements. We should expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example.
> The new table will need to be registered in {{SystemViewsKeyspace}}.
> Some unit tests will need to be added. For some example of virtual table
> tests you can look at {{SystemPropertiesTableTest}} and for some example of
> test around prepared statement metrics you can look into {{CQLMetricsTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17236:
--
Assignee: (was: Shailaja Koppu)
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and
> (\-\-version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the (--v) option to spit the version info.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17236:
--
Assignee: Shailaja Koppu
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Assignee: Shailaja Koppu
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and
> (\-\-version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the (--v) option to spit the version info.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17236:
--
Assignee: (was: Shailaja Koppu)
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and
> (\-\-version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the (--v) option to spit the version info.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17236:
--
Assignee: Shailaja Koppu
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Assignee: Shailaja Koppu
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and
> (\-\-version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the (--v) option to spit the version info.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
