stolon
stolon copied to clipboard
sorintlab
To support online reload of super user and replication user credentials
What would you like to be added: It would be nice to provide a reload option or some sort to let know stolon that credentials are changed than what it was started with initially.
Why is this needed: Currently, we have to restart stolon keeper which causes downtime.
@viggy28 If you update the superuser credentials probably the primary will fail its checks and become failed before you'll be able to update its state. So to achieve this you should automate this in a very fast way.
Regardless of the difficulties explained above, now usernames are read from a command line argument and passwords too or from a file provided in the command line (and these parameter can be also provided using env vars). This is implemented in this way since we don't want to save passwords in the cluster spec.
So without changes to the way we get the credentials we'll be able to update only the passwords and only if provided in a file that should be updated (and then a SIGHUP could be sent to the keeper process).
If there's the need to also reread the users it will require more changes.
If you update the superuser credentials probably the primary will fail its checks and become failed before you'll be able to update its state. So to achieve this you should automate this in a very fast way.
Yeah, so the operator (who wants to change the password) should first increase the failInterval to a sufficient large duration.
So without changes to the way we get the credentials we'll be able to update only the passwords and only if provided in a file that should be updated (and then a SIGHUP could be sent to the keeper process).
Makes sense. Shall I look to implement the support of password change for now? (Since passwords are rotated often for compliance or security purpose)
Makes sense. Shall I look to implement the support of password change for now? (Since passwords are rotated often for compliance or security purpose)
Feel free if you implement it if you have time. Then, if more requirements arises, we could add other ways to define credentials (like a single config file containing both users and passwords). Thanks!