-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace cass-config-builder with Go #512
Comments
A small note to overall approach. We need the base config in many cases, but that's not available elsewhere than the image itself. So perhaps initcontainer is still necessary (or sane approach). |
Reopening until cass-operator part is merged also. |
hello @burmanm Is it still possible to use cass-config-builder over k8ssandra-client for cassandra 4.1 ?
Do you know where I can find documentation about cass-config-builder and Cassandra 4.1 compatibility? Thanks! |
You need to override two init containers if you wish to use the older one, we automatically deploy k8ssandra-client for 4.1 installations. cass-config-builder has no support for 4.1 and is not tested with it. It would deploy 4.0.0 config as the base template for 4.1. Why would you want to use the old cass-config-builder instead? |
Thank you for your answer!
That's a long story. To make it short, we have to get the k8ssandra-client image approved by our customers security teams, while the cass-config-builder image is already approved |
Right. Well, it might make sense to get that process done as our active work revolves around k8ssandra-client for config building. That includes 5.0 support also. |
What is missing?
We currently run cass-config-builder, which is not compatible with the new configs in 4.1 and up. The steps that we will need to implement are created as subtickets (we don't need to replicate entire cass-config-builder as a lot of it isn't Kubernetes related).
In addition, some smaller ones:
Why is this needed?
Refactoring cass-config-builder is time consuming, is built on language we don't use (Clojure) and it's a resource hog.
Additional info
We need to decide which versions will use the newer builder. Do we want to keep the old one for the stuff where it has worked previously (3.11.x, 4.0.x and DSE 6.8.x) and only use it for the newer stuff - or do we want to replace and use a common path for all versions?
Restricting it to newer ones would reduce the amount of boilerplate and different paths, but of course would require different deployment model for different versions.
The text was updated successfully, but these errors were encountered: