This is turning into an incredible rabbit hole of programming languages and slightly relates to the recent discussion on that. So far, I've come across: Go, Python (2 and 3), Erlang, C (somehow?), JavaScript, Bash, Groovy (mostly via Gradle), and that's not even touching on the languages in use here!
Anyways, the CouchDB patch to support DNS SRV records looks like a fruitful approach, so I'm trying to fix up the existing PR first before attempting the operator-based route. I did look at KubeDB, and it looks neat, though notes on how to create a new database integration are scarce at the moment. That framework does look very useful, though, for building a proper K8s operator for CouchDB which would make our own Helm charts simpler. On Sat, 20 Jul 2019 at 14:39, Michele Sciabarra <mich...@sciabarra.com> wrote: > > I world consider addimg Couchdb support To a project like this > https://kubedb.com/ since is supports very different dbs probably it is > easier than starts from scratch > > -- > Michele Sciabarra > mich...@sciabarra.com > > > > ----- Original message ----- > From: Matt Sicker <boa...@gmail.com> > To: dev@openwhisk.apache.org > Subject: Re: Looking to contribute; which areas need some love? > Date: Saturday, July 20, 2019 9:28 PM > > Unfortunately, the couchdb operator is unlicensed and hasn't been > updated in a couple years. That does indicate that the author is > _probably_ willing to either donate the code or attach a proper > license to it at least. I filed an issue [1], so perhaps this route > might work out after all. > > [1]: https://github.com/nicolai86/couchdb-operator/issues/1 > > On Sat, 20 Jul 2019 at 14:15, Matt Sicker <boa...@gmail.com> wrote: > > > > Oh this is fun doing archeology on other projects (CouchDB in this > > case). I recognize one of the typical PR reviewers from elsewhere, and > > it appears that the DNS SRV based cluster discovery feature hasn't > > been merged upstream yet. This might turn into a neat opportunity for > > us to connect more with the CouchDB PMC. I'll link back any upstream > > issues. > > > > On Sat, 20 Jul 2019 at 14:02, Matt Sicker <boa...@gmail.com> wrote: > > > > > > Thanks for the link! That looks like an even easier way to support > > > CouchDB for sure. I'll play around with each option to see which makes > > > more sense to prototype. > > > > > > On Sat, 20 Jul 2019 at 13:41, Michele Sciabarra <mich...@sciabarra.com> > > > wrote: > > > > > > > > A critical aspect to consider is backup. There is an operator in the > > > > work (that is the primary reason so far to use an external CouchDB) > > > > There is an operator in the work that may be useful > > > > https://github.com/nicolai86/couchdb-operator > > > > > > > > -- > > > > Michele Sciabarra > > > > mich...@sciabarra.com > > > > > > > > > > > > > > > > ----- Original message ----- > > > > From: Matt Sicker <boa...@gmail.com> > > > > To: dev@openwhisk.apache.org > > > > Subject: Re: Looking to contribute; which areas need some love? > > > > Date: Saturday, July 20, 2019 8:03 PM > > > > > > > > Continuing discussion in > > > > https://github.com/apache/incubator-openwhisk-deploy-kube/issues/498 > > > > > > > > On Sat, 20 Jul 2019 at 12:48, Matt Sicker <boa...@gmail.com> wrote: > > > > > > > > > > So it seems that there's an incubating chart for CouchDB already which > > > > > might be adaptable: > > > > > https://github.com/helm/charts/tree/master/incubator/couchdb > > > > > > > > > > Main difference I already see is that they offer a StatefulSet for > > > > > clustering the CouchDB instances. Might not be too complicated. I'll > > > > > file an issue since I wasn't able to find any existing ones. > > > > > > > > > > On Fri, 19 Jul 2019 at 14:41, Matt Sicker <boa...@gmail.com> wrote: > > > > > > > > > > > > That does sound like an interesting thing to do. I've been looking > > > > > > for > > > > > > an excuse to practice more Kubernetes things, so this could be > > > > > > rather > > > > > > practical there. > > > > > > > > > > > > On Fri, 19 Jul 2019 at 13:21, Michele Sciabarra > > > > > > <mich...@sciabarra.com> wrote: > > > > > > > > > > > > > > In my opinion, given your experience with Kubernetes, a long > > > > > > > needed feature is to add support for clustered CouchDb in the > > > > > > > helm chart. It is the only missing pieces to allow for a true > > > > > > > ‘production’ CouchDb. Kafka is already clustered, CouchDb is not. > > > > > > > David recommend to use an external one but it is not always an > > > > > > > option when you have an internal deployment for example. > > > > > > > > > > > > > > -- > > > > > > > Michele Sciabarra > > > > > > > mich...@sciabarra.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original message ----- > > > > > > > From: Matt Sicker <boa...@gmail.com> > > > > > > > To: dev@openwhisk.apache.org > > > > > > > Subject: Looking to contribute; which areas need some love? > > > > > > > Date: Friday, July 19, 2019 7:10 PM > > > > > > > > > > > > > > Hey all, I've been working on some other personal project the > > > > > > > past few > > > > > > > weekends, but I've been itching to explore this project more and > > > > > > > make > > > > > > > some code contributions. I see the main openwhisk repo is > > > > > > > Scala/Akka > > > > > > > which is tech that I've used before. However, I'm also interested > > > > > > > in > > > > > > > hearing which areas feel neglected right now and could use some > > > > > > > attention. > > > > > > > > > > > > > > As a bonus, this can also start an idea of adding entries to > > > > > > > https://helpwanted.apache.org/ to recruit more contributors. I see > > > > > > > there's already some GSoC projects going on, so this is an > > > > > > > additional > > > > > > > resource that can be useful here. > > > > > > > > > > > > > > -- > > > > > > > Matt Sicker <boa...@gmail.com> > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Matt Sicker <boa...@gmail.com> > > > > > > > > > > > > > > > > > > > > -- > > > > > Matt Sicker <boa...@gmail.com> > > > > > > > > > > > > > > > > -- > > > > Matt Sicker <boa...@gmail.com> > > > > > > > > > > > > > -- > > > Matt Sicker <boa...@gmail.com> > > > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > > > -- > Matt Sicker <boa...@gmail.com> > -- Matt Sicker <boa...@gmail.com>
