Amazon Keyspaces Commitment to OSS скачать в хорошем качестве

Amazon Keyspaces Commitment to OSS

Join Yash, Himanshu, and Joel from the Amazon Keyspaces team as they discuss AWS's evolving commitment to contributing to Apache Cassandra Open Source. The presentation covers a three-pronged strategy involving community presence, small code initiatives, and large, complex projects like CEP-50. AWS Contributions to Apache Cassandra Infrastructure: AWS has donated infrastructure for running Cassandra builds for over five years and more recently provided credits and a Jenkins cluster for a community-owned pre-commit testing infrastructure. This helps smaller, independent contributors run the necessary distributed tests. Code: Collaborated on improving automated repairs , adding guardrails to prevent repairs during version upgrades (due to data incompatibility) and when disk usage is too high (due to temporary disk space needs). Deep Dive into CEP-50: Authenticator Negotiation Joel Shepard introduces CEP-50 (Authenticator Negotiation), a proposal to modernize how clients and nodes agree on an authentication method. Today, Cassandra supports only a single authenticator at runtime, making migration and multi-client support extremely difficult. Goals of Negotiation Seamless Migration: Allows for migrating your Cassandra installation to a new authenticator without disruption (e.g., from password to IAM credentials). Multiple Clients/Methods: Enables different client applications (e.g., SQL Shell vs. Services) to use different authentication methods simultaneously against the same cluster. Node Control: Gives the node the final decision on the authentication method, based on its preferred list and the client's capabilities. How the Handshake Changes (Introducing Protocol V6) The new process adds a negotiation step to the client-node handshake: Options: Client asks the server what it supports. Supported: Server replies with a new option, authenticators, indicating it supports negotiation. Startup: Client sends a list of authenticators it can use. Authenticate: The server picks its most preferred authenticator from the client's list and proceeds with the standard challenge-response flow. Implementation Challenges Standardizing Identity: Creating a shared language/key (like authentic_mode) for the client and node to identify authenticators, as class names are often ignored by drivers today. Refactoring Code: Breaking the fundamental, pervasive assumption in the Cassandra code base that "there is one and only one authenticator" at runtime. Global State: Addressing the global state/singleton-like behavior in many existing authenticators. This work is intended to be backwards compatible and will likely introduce a new Protocol Version (V6). The next steps include a reference implementation in the Java driver and eventually using this framework to support IAM-based authentication.