k8ssandra/reaper-client-go

A Go client library for the Cassandra Reaper REST API

[DEPRECATED]

This project is deprecated and replaced by k8ssandra-operator

Read this blog post to see what differences exist between K8ssandra and k8ssandra-operator, and why we decided to build an operator.
Follow our migration guide to migrate from K8ssandra (and Apache Cassandra®) to k8ssandra-operator.

K8ssandra

K8ssandra is a simple to manage, production-ready, distribution of Apache Cassandra and Stargate that is ready for Kubernetes. It is built on a foundation of rock-solid open-source projects covering both the transactional and operational aspects of Cassandra deployments. This project is distributed as a collection of Helm charts. Feel free to fork the repo and contribute. If you're looking to install K8ssandra head over to the Quickstarts.

Components

K8ssandra is composed of a number of sub-charts each representing a component in the K8ssandra stack. The default installation is focused on developer deployments with all of the features enabled and configured for running with a minimal set of resources. Many of these components may be deployed independently in a centralized fashion. Below is a list of the components in the K8ssandra stack with links to the appropriate projects.

Apache Cassandra

K8ssandra packages and deploys Apache Cassandra via the cass-operator project. Each Cassandra container has the Management API for Apache Cassandra (MAAC) and Metrics Collector for Apache Cassandra(MCAC) pre-installed and configured to come up automatically.

Stargate

Stargate provides a collection of horizontally scalable API endpoints for interacting with Cassandra databases. Developers may leverage REST and GraphQL alongside the traditional CQL interfaces. With Stargate operations teams gain the ability to independently scale coordination (Stargate) and data (Cassandra) layers. In some use-cases, this has resulted in a lower TCO and smaller infrastructure footprint.

Monitoring

Monitoring includes the collection, storage, and visualization of metrics. Along with the previously mentioned MCAC, K8ssandra utilizes Prometheus and Grafana for the storage and visualization of metrics. Installation and management of these pieces is handled by the Kube Prometheus Stack Helm chart.

Repairs

The Last Pickle Reaper is used to schedule and manage repairs in Cassandra. It provides a web interface to visualize repair progress and manage activity.

Backup & Restore

Another project from The Last Pickle, Medusa, manages the backup and restore of K8ssandra clusters.

Next Steps

If you are looking to run K8ssandra in your Kubernetes environment check out the Getting Started guide, with follow-up details for developers and site reliability engineers.

We are always looking for contributions to the docs, helm charts, and underlying components. Check out the code contribution guide and docs contribution guide

If you are a developer interested in working with the K8ssandra code, here is a guide that will give you an introduction to:

• Important technologies and learning resources
• Project components
• Project processes and resources
• Getting up and running with a basic IDE environment
• Deploying to a local docker-based cluster environment (kind)
• Understanding the K8ssandra project structure
• Running unit tests
• Troubleshooting tips

Dependencies

For information on the packaged dependencies of K8ssandra and their licenses, check out our open source report.

reaper-client-go's Issues

Integrate Fossa component/license scanning

• Integrate via GH Actions to automate scanning and reporting

• Investigate how reports can be made public (hopefully via Fossa)

┆Issue is synchronized with this Jiraserver Task by Unito
┆Reviewer: 5dc217efb6e6b50c58aecb40
┆Issue Number: K8SSAND-565
┆Priority: Medium

Implement an exhaustive API for Reaper

I would like to implement an exhaustive API for Reaper.

The current state of the art is:

• Some of the exposed REST methods are implemented, mostly in the Cluster and RepairSchedule resources, but not all of the optional parameters are available.
• A PR #3 is open to add an initial support for the RepairRun resource, again not all of the methods and optional parameters are implemented.

Here is my proposal:

• Complete the existing resources by adding the missing methods and/or parameters, re-using the material in #3 for RepairRun methods.
• Add support for missing resources, and mostly: Snapshot and Node.
• Add support for authentication.
• Add tests for new methods reusing the current (and excellent) test environment using Docker.

These things can of course be done little by little, and by different developers.

But I think it would be important to agree on the desired API first.

Indeed, some of the existing API methods and types might need to be renamed or re-engineered to comply with things like:

• consistent naming of types, and methods and parameters
• consistent mapping of REST endpoints to Go methods
• how to expose optional parameters
• consistent behavior (consistent error messages, etc.)

Also, I think it is important to settle on a common code related to HTTP plumbery, so that new methods can be implemented faster and more reliably. This will likely require some refactoring of the existing HTTP-related functions.

I took the initiative to bootstrap a design document with a proposal for a revised API:

https://docs.google.com/document/d/1xau9Lr9BsctZBgpoFnWJmmkFz5c885O8MhqkGWMca1I/edit?usp=sharing

Feel free to add comments there or here.

If/when we agree on the proposed changes, I can start working on this ASAP and provide implementations for the most important resources as a first step: Login, Ping, Cluster, RepairRun and RepairSchedule.

┆Issue is synchronized with this Jiraserver Task by Unito
┆Issue Number: K8SSAND-496
┆Priority: Medium