Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out a way to avoid manual action after deploying a cluster with the helm chart #92

Open
colearendt opened this issue Jul 27, 2022 · 2 comments

Comments

@colearendt
Copy link
Contributor

colearendt commented Jul 27, 2022

Is your feature request related to a problem? Please describe.
After deploying the helm chart, there is a very helpful / explanatory message in NOTES.txt about cluster state:

Once all of the Pods are fully Ready, execute the following command to create
some required system databases

Describe the solution you'd like
It would be nice if this manual command did not need to be run. What is it for? Is there a way to deploy a one-shot job or something alongside that will do this bootstrapping for us? What are the downsides if you run this command multiple times?

At a minimum, the quoting on the command was a little off which made it tricky to use

Describe alternatives you've considered

Additional context

It also surprises me that this is printed every time. I suspect there are values in helm that we could use to determine whether this is necessary to print. For instance, I'm pretty sure you can tell when you have an install vs. an upgrade.

Once all of the Pods are fully Ready, execute the following command to create
some required system databases:
kubectl exec --namespace {{ .Release.Namespace }} {{ if not .Values.allowAdminParty }}-it {{ end }}{{ template "couchdb.fullname" . }}-0 -c couchdb -- \

@colearendt
Copy link
Contributor Author

colearendt commented Jul 29, 2022

Just a bit more digging on this. At a minimum, this request seems to create the _replicator and _users databases.

It is also not idempotent:

First response:

curl -i -s http:https://127.0.0.1:5984/_cluster_setup -XPOST -H 'Content-Type: application/json' -d '{"action": "finish_cluster"}' -u admin
Enter host password for user 'admin':
HTTP/1.1 201 Created
Cache-Control: must-revalidate
Content-Length: 12
Content-Type: application/json
Date: Fri, 29 Jul 2022 13:38:34 GMT
Server: CouchDB/3.2.1 (Erlang OTP/23)
X-Couch-Request-ID: 4786904116
X-CouchDB-Body-Time: 0

{"ok":true}

Second:

curl -i -s http:https://127.0.0.1:5984/_cluster_setup -XPOST -H 'Content-Type: application/json' -d '{"action": "finish_cluster"}' -u admin
Enter host password for user 'admin':
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate
Content-Length: 63
Content-Type: application/json
Date: Fri, 29 Jul 2022 13:35:24 GMT
Server: CouchDB/3.2.1 (Erlang OTP/23)

{"error":"bad_request","reason":"Cluster is already finished"}

@fsalazarh
Copy link
Contributor

Hi @colearendt,

I contributed with automation of placement couchdb nodes across availability zones in the cluster.

You can use the placementConfig parameters in values.yaml to use this feature, and in the last step the creation of system databases is executed in order to avoid manually steps on cluster creation.

Please use the tag 0.3.0 in placementConfig.image.tagin order to use the latest version of placement-manager code.

I understand that you may not want to automate the placement of nodes across availability zones, but it's useful if you're using a cluster in a cloud environment like AWS and you want to configure HA, for example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants