[ https://issues.apache.org/jira/browse/CASSANDRA-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159517#comment-14159517 ]
Aleksey Yeschenko edited comment on CASSANDRA-8032 at 10/5/14 1:01 PM: ----------------------------------------------------------------------- Right. AFAIK this feature isn't really being used by people. As for "finer granularity of control, from read-only vs read-write users on keyspaces" - you can have table-level granularity for authorization there using the IAuthenticator+IAuthorizer APIs. Using it for "virtual datacenter" bulding would be a hack, and on its own it's not enough to support true multitenancy - you need better resource isolation/usage limits support, deep and on all levels, to make that happen. So I'd say let it go, for now, until more suitable times, and close CASSANDRA-8059 - you'll have a hard time convincing other committers that the changes to CQL Statement classes are justified, given that this would not *really* bring us any closer to multitenancy, and on its own the feature request is very niche. was (Author: iamaleksey): Right. This feature AFAIK, this feature isn't really being used by people. As for "finer granularity of control, from read-only vs read-write users on keyspaces" - you can have table-level granularity for authorization there using the IAuthenticator+IAuthorizer APIs. Using it for "virtual datacenter" bulding would be a hack, and on its own it's not enough to support true multitenancy - you need better resource isolation/usage limits support, deep and on all levels, to make that happen. So I'd say let it go, for now, until more suitable times, and close CASSANDRA-8059 - you'll have a hard time convincing other committers are justified, given that this would not *really* bring us any closer to multitenancy, and on its own the feature request is very niche. > User based request scheduler > ---------------------------- > > Key: CASSANDRA-8032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8032 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: mck > Assignee: mck > Priority: Minor > Labels: patch > Attachments: v1-0001-CASSANDRA-8032-User-based-request-scheduler.txt > > > Today only a keyspace based request scheduler exists. > Post CASSANDRA-4898 it could be possible to implement a request_scheduler > based on users (from system_auth.credentials) rather than keyspaces. This > could offer a finer granularity of control, from read-only vs read-write > users on keyspaces, to application dedicated vs ad-hoc users. Alternatively > it could also offer a granularity larger and easier to work with than per > keyspace. > The request scheduler is a useful concept but i think that setups with enough > nodes often favour separate clusters rather than either creating separate > virtual datacenters or using the request scheduler. To give the request > scheduler another, and more flexible, implementation could especially help > those users that don't yet have enough nodes to warrant separate clusters, or > even separate virtual datacenters. On such smaller clusters cassandra can > still be seen as an unstable technology because poor consumers/schemas can > easily affect, even bring down, a whole cluster. > I haven't look into the feasibility of this within the code, but it comes to > mind as rather simple, and i would be interested in offering a patch if the > idea carries validity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)