Support official Cassandra Docker images #222
Comments
|
👍 although I am not interested in supporting multiple different images at this point. Differences in entrypoint, config directory etc. will be a pain to handle well as that information needs expressing on the *Cluster resource, and then passing all the way down and through. I'd rather us focus on other core parts, and for now have a fixed series of Docker images that can be used. As and when we have a requirement for custom images, we can focus on that. For now, scale down/upgrade etc etc are much higher priority. |
|
FWIW, I'm not against us switching which Docker images we use for this if you would prefer to use the 'official' ones (side note: who makes these images?). Specifically I don't think we should complicate our APIs right now with supporting fields to allow this to be completely customised by the user, as I fear a user could start using an image that does something differently, and then when it comes to designing our upgrade process or the like, we have to make assumptions that are now false. By controlling it for now, we will gain an understanding of what requirements we need to put on the images that are used, so when it comes to adding support for arbitrary custom images we will have a bullet pointed list of requirements of the images that are used. |
|
I'd rather switch to using better supported images. Cassandra from kubernetes/examples doesn't seem well supported, with the last updates from May of last year (currently on 3.10, while 3.11 was released in june). The cassandra image on dockerhub is supported by docker, inc (https://docs.docker.com/docker-hub/official_repos/). They should provide security updates and general maintenance. |
* Use the Docker maintained Cassandra 3 image. * Temporarily use TCP connect based readiness and liveness probes because this image doesn't contain a nodetool based `/ready-probe.sh` script. * I found that these TCP connection checks succeed even when the process is SIGSTOPped; so I now simulate a node failure using `nodetool decommission` which makes cassandra stop listening on its CQL port. * Cluster status aware readiness probes will be restored jetstack#170 is merged. Fixes: jetstack#222
Automatic merge from submit-queue. Use the Docker maintained Cassandra 3 image * Use the Docker maintained Cassandra 3 image. * Use TCP connect based readiness and liveness probe because this image doesn't contain a nodetool based `/ready-probe.sh` script. * These TCP connection checks will succeed even though the process is stopped; so I now simulate a node failure using `nodetool decommission` which makes cassandra stop listening on its CQL port. * I can improve on this when #170 is merged. Fixes: #222 **Release note**: ```release-note NONE ```
We're currently using the Google maintained Cassandra image from the Cassandra + Kubernetes demo.
We should also support other, official, Cassandra V3 images such as:
One key difference in that image is that it has a different entrypoint.
So the hard coded
/run.shin https://github.com/jetstack/navigator/blob/master/pkg/pilot/cassandra/v3/pilot.go#L56 needs to be configurable somehow....or auto detected...if that's possible./kind feature
The text was updated successfully, but these errors were encountered: