Actually I was wondering why you have a monolitic chart deploying everything, when there are plenty of "stable" helm chart for deploying kafka or redis or couch.
The whole chart should be IHMO split in multiple subchart. Or better, write a kubernetes operator for OpenWhisk ... that would be outstanding and give him an edge... -- Michele Sciabarra [email protected] ----- Original message ----- From: David P Grove <[email protected]> To: [email protected] Subject: Re: What are the requirements for clustered CouchDB? Date: Wednesday, April 24, 2019 7:41 PM "Michele Sciabarra" <[email protected]> wrote on 04/24/2019 05:01:59 AM: > > So far I always saw OpenWhisk running either with Cloudant or with a > single node CouchDB. > In the latest release of the helm chart it is recommended to use an > external couchdb. Hi, I should probably try to motivate this recommendation better in the deploy-kube documentation. For development purposes, deploying the database in lockstep with the rest of OpenWhisk via a single Helm chart makes complete sense. For a production scenario, you don't want to tightly couple the life cycle of the database with that of the rest of OpenWhisk. For example, you want to be able to hot swap your OpenWhisk core system to a new version without wiping the database (all the user actions, activations, etc). You may want multiple instances of OpenWhisk connected to the same database (blue/green or hot spares). Therefore, in production you should deploy the database separately and manage it external to the Helm chart that is used to deploy the core system. "External" could be either really running outside of Kubernetes or running on the same Kubernetes cluster but managed externally from the perspective of the Helm chart for OpenWhisk. Both of those scenarios are the same from the view point of the Helm chart. --dave
