### Problem to solve GitLab Administrators want to be able to script and automate setting the Geo Replication Password with the ability to get feedback that the password has been changed. Example: ```bash /usr/bin/expect <<EOD log_user 0 spawn gitlab-ctl set-replication-password expect "Enter password:" send "${rep_password}\n" expect "Confirm password:" send "${rep_password}\n" echo "${rep_password}" > see_password.txt EOD ``` ### Intended users GitLab System Administrators ### User experience goal The goal is to automate the setup and configuration of GitLab Geo. ### Proposal Create an ability to set the password through the command line and ability to acknowledge that the change was made. ### Further details Feedback from GitLab Administrator: >>> I currently have no way of validating that the password I'm changing (setting the replication password) is reliably changing said password. I have no knowledge of any APIs that I can access to change or check the password. All I know is it would appear that this does not seem to work and without said APIs I'm blind to knowing what the issue could be. >>> In a discussion in our slack: https://gitlab.slack.com/archives/C32LCGC1H/p1589824906076900 (internal link), following the request from the customer: >>> The script adminname and I had been working on was building Gitlab in a replicated way following the instructions outlined here. https://docs.gitlab.com/ee/administration/geo/replication/database.html If you have a script for the automation of this process that would help greatly. If you have a more effective way to automate that goes beyond bash scripting I'm all ears to that too. >>> ### Possible solution for confirming that it succeeded `ALTER USER` returns `ALTER USER`, so if we see that output, then at least we know an error didn't happen: ```sh sudo gitlab-psql -c "ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';" ALTER USER ``` I suppose we could check for that output inside of `set-replication-password`. Though I would already expect `set-replication-password` to fail if `ALTER USER` fails. Does it not? ### Possible solution for easier automation of `set-replication-password` Make the command accept a password option as an alternative to using a prompt.