...
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
...
Scope
todoThe scope of this CEP is to design a framework for easily adding system-wide soft and hard limits.
Goals
- Easy way to enforce system-wide soft and hard limits to prevent anti-patterns of bad usage and in the long run make it not possible to severely degrade the performance of a node/cluster through user actions (too many MVs/secondary indexes per table, ...), thus increasing stability/availability.
- As a C* developer it should be easy to add new Guardrails.
- Guardrails are disabled by default and there should be no overhead when Guardrails are disabled.
- Guardrails are configured in cassandra.yaml and can also be dynamically modified through JMX and/or virtual tables.
- Guardrails emit issue warnings/failures to the server log file, and also to the client connection when applicable.
Non-Goals
- enforcing Enforcing limits on a per-user-basissetting limits dynamically while nodes are running.
Timeline
todo
Mailing list / Slack channels
...
Guardrails allow C* operators to impose system-wide restrictions that are configured through yaml and JMX/virtual tables. Capability restrictions are focused on imposing restrictions on particular users and offer a new CQL API to do so. Both concepts are not mutually exclusive and are complementary, and capabilities restrictions can be developed either independently or as an extension of the proposed system-wide guardrails.
Event logging
In their initial form, Guardrails would issue warnings/failures to the server log file, and also to the client connection. Some guardrails can be used in processes that are not linked to a client connection, such as compaction. In that case the warnings/failures would be issued only to the server log file. As for propagating warnings and failures to clients, we might require to do some changes in drivers, so they are able to display detailed messages.
...