Allow setting of consistent admin password hash

[arnediekmann]

What this PR does / why we need it:

This PR allows the usage of a hash for the admin user instead of a password which will ensure that the admin hash is consistent between different nodes. This circumvents the problem described in apache/couchdb#1781.

Checklist

• Chart Version bumped
• e2e tests pass
• Variables are documented in the README.md
• Chart tgz added to /docs and index updated

[willholley]

merged in #26

[realvasko]

Hi @arnediekmann,

I tried using this, together with createAdminSecret: false. That is, I generated the hash, put it in an ini file and added it to the secret that I manually created (the documentation on this is slightly incorrect, btw -- it should not be 'my-password.ini', just 'password.ini', as this is the key that will be used in the secret). This didn't work though and from reviewing the chart (not really an expert on writing helm charts, so I might be completely wrong) I believe it's because the entry in the secret is never used. It's written, if adminHash is set, which also triggers the generation and copy of the ini-file. But if adminHash is not set, the secret attribute is not considered and the file is not generated nor copied. Or am I missing something else here?

[GeorgFleig]

You're right @realvasko, the chart's logic to use the pre-defined admin password hash is broken. It does actually work using the chart, but the values required to get it to work are quite confusing..

Here is how I got it working:

1. The key in the secret for the password.ini file must be password.ini, not my-password.ini as you figured out as well.
2. The adminPassword key inside the secret must still be set (random value is fine) as it is required by the StatefulSet environment variables.
3. Set adminHash in the values.yaml to true so the logic in the init container is is enabled to copy the contents of the password.ini of the secret to the right place. The README suggests this variable could contain the admin password hash but the content is never evaluated at all.

[willholley]

note this behaviour is changed/simplified following #106