On Fri, Sep 20, 2019 at 8:09 AM Ben Bromhead <b...@instaclustr.com> wrote: > > Providing an official docker image is a little tricky, as despite what > container marketing would tell you, containers need to make assumptions > about outside orchestration/management methods. Folks in this thread have > already identified differences in kubernetes distro's let alone other > container schedulers.
Just to clarify the proposal Vinay and I made at the summit, I don't think that we can provide a single image that works for every single use case just like Cassandra's out of the box debian package does not work perfectly out of the box for many configuration management / orchestration systems, nor did I intend to propose we provide an official image for kubernetes, marathon, DCOS, or whichever new scheduler is popular these days. I do think we can offer two generally configurable and reasonable base Cassandra containers, one for testing and one for production. Both containers must provide the requisite pluggability seams for common use cases just like the debian and rpm packages do. For example, a pluggable configuration file (I usually offer overrides via environment variables in my images), ability to call a user provided bash script before starting the daemon, a way to change jvm options, etc ... These seams would then be documented so that people can easily plug in their needed functionality. The testing image would optimize for fast startup and single node clusters (e.g. turning off vnodes, skipping integrity checks, etc ...). The production image would naturally not turn these things off. If a user cannot plug-in their functionality then they can raise a bug report explaining the difficulty and we can either add the needed seam or say "sounds like you need a custom image". It would be nice if the community contributed documentation for "here is how you take the production image and run it on kubernetes" but I don't think the Cassandra developers need to maintain this integration. Yes, these will not satisfy every use case, but they are still very valuable even if only as a starting point for the community. -Joey --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
