You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Michele Sciabarra <mi...@sciabarra.com> on 2019/04/24 09:01:59 UTC
What are the requirements for clustered CouchDB?
Hi whiskers,
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.
So my question is: does OpenWhisk work with a clustered CouchDB as described here? https://docs.couchdb.org/en/stable/cluster/index.html
Is there a significant penalty running it in Kubernetes instead?
--
Michele Sciabarra
michele@sciabarra.com
Re: What are the requirements for clustered CouchDB?
Posted by David P Grove <gr...@us.ibm.com>.
"Michele Sciabarra" <mi...@sciabarra.com> wrote on 04/24/2019 01:46:06
PM:
>
> 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.
That's where we started (multiple subcharts). It was a mess because Helm's
support for sharing information across multiple charts is too weak. We
gave up. The value of using "stable" charts for standard components was
far out-weighed by the ugliness of the rest of it with lots of replication
and use of globals.
Maybe we didn't do it right, but we tried pretty hard for a while before we
gave up. Look back in git history around May of 2018 if you want to see
what was there.
--dave
>
> Or better, write a kubernetes operator for OpenWhisk ... that would
> be outstanding and give him an edge...
>
I think user-focused operators for OpenWhisk are more compelling. There
actually are some here [1] that allow managing resources like functions,
triggers, and rules via Kubernetes operators.
--dave
[1] https://github.com/IBM/openwhisk-operator
Re: What are the requirements for clustered CouchDB?
Posted by Michele Sciabarra <mi...@sciabarra.com>.
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
michele@sciabarra.com
----- Original message -----
From: David P Grove <gr...@us.ibm.com>
To: dev@openwhisk.apache.org
Subject: Re: What are the requirements for clustered CouchDB?
Date: Wednesday, April 24, 2019 7:41 PM
"Michele Sciabarra" <mi...@sciabarra.com> 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
Re: What are the requirements for clustered CouchDB?
Posted by David P Grove <gr...@us.ibm.com>.
"Michele Sciabarra" <mi...@sciabarra.com> 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
Re: What are the requirements for clustered CouchDB?
Posted by Dominic Kim <st...@gmail.com>.
I have not tested with K8S, but native OpenWhisk works well with a
clustered CouchDB.
Even it includes procedures to deploy CouchDB as a cluster.
https://github.com/apache/incubator-openwhisk/blob/master/ansible/roles/couchdb/tasks/deploy.yml#L134
Best regards
Dominic
2019년 4월 24일 (수) 오후 6:02, Michele Sciabarra <mi...@sciabarra.com>님이 작성:
> Hi whiskers,
>
> 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.
>
> So my question is: does OpenWhisk work with a clustered CouchDB as
> described here? https://docs.couchdb.org/en/stable/cluster/index.html
>
> Is there a significant penalty running it in Kubernetes instead?
>
>
> --
> Michele Sciabarra
> michele@sciabarra.com
>